[gnso-rds-pdp-wg] Why the thin data is necessary
Volker Greimann
vgreimann at key-systems.net
Wed Jun 7 11:16:25 UTC 2017
Authentification does not necessariliy mean restriction. There are many
means of authentification options that we may chose for this data that
do not restrict in the least bit who can access this data. It only
places a barrier of how easily this may be accessed, unless we decide
differently down the road. As we can have multiple access tiers, this is
both practical and sensible. In this case your argument does not cut bread.
Best,
Volker
Am 07.06.2017 um 13:08 schrieb jonathan matkowsky:
> Volker, you said that spam tied to the lifecycle of a domain with fake
> renewals and SEO notices was a basis for restricting access. I was
> pointing out that not only isn't it a basis for doing so, it is
> actually prevents the public from being able to avoid being scammed.
> Then you said you see no harm in such restrictions in any event. And I
> was pointing out that there is in fact harm. The harm is that
> authentication requires private information to be disclosed. And that
> should not be done unless there is a good reason for doing so. And
> there is none, as per above.
>
> Jonathan Matkowsky,
> VP – IP & Brand Security
> USA:: 1.347.467.1193 | Office:: +972-(0)8-926-2766
> Emergency mobile:: +972-(0)54-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 12:30 PM, 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/
>>> <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 <tel:+49%206894%209396901>
>>> Fax.: +49 (0) 6894 - 9396 851 <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>
>>> 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 <tel:+49%206894%209396901>
>>> Fax.: +49 (0) 6894 - 9396 851 <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>
>>> 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
>>> <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 <tel:+49%206894%209396901>
>> Fax.:+49 (0) 6894 - 9396 851 <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>
>> 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 <tel:+49%206894%209396901>
>> Fax.:+49 (0) 6894 - 9396 851 <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>
>> 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.
>>
>>
>>
>> --
>> 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 <tel:+49%206894%209396901>
> Fax.:+49 (0) 6894 - 9396 851 <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>
> 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 <tel:+49%206894%209396901>
> Fax.:+49 (0) 6894 - 9396 851 <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>
> 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.
>
>
>
>
--
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170607/d9914db4/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list