[gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes from Next-Generation RDS PDP Working Group Call - 17 May 2017
Paul Keating
Paul at law.es
Wed May 17 17:10:14 UTC 2017
+1
On 5/17/17, 6:40 PM, "Michael Peddemors"
<gnso-rds-pdp-wg-bounces at icann.org on behalf of michael at linuxmagic.com>
wrote:
>Yes, this is the common argument, however IMHO this is a red herring..
>There are more efficient ways for 'harvesters' to gain data, and others
>way to prevent such abuse..
>
>Again, IMHO this argument is another case of impacting the many
>legitimate users, for the sake of a few bad apples..
>
>And I havent' seen any arguments yet, of a case scenario which can't be
>addressed by other means..
>
>* Spammers can find better databases (less tech savvy targets, and
>cheaper than data mining whois records) by buying online lists of
>compromised email account data.
>* Fake Domain Renewal Notices? Again, a selected few who are quickly
>listed as spammers, and should be pursued via alternative (law
>enforcement/legal) methods.
>
>Yet we can show many case scenarios's where that data availability
>provides productive information for abuse prevention, that are not
>available via other means..
>
>This argument still needs to be put to bed.. and it should be based on
>case scenario arguments, and not just the 'perception' of abuse, and
>abuse is abuse and should be treated as such..
>
>And this is part of this process, making those valued decisions of what
>data SHOULD be freely available, and what data doesn't need to be
>available, or where the risks outweigh the rewards..
>
>(and of course the 'thorny' argument of privacy legislation(s) in
>various jurisdictions)
>
>On 17-05-17 09:14 AM, Volker Greimann wrote:
>> To prevent abuse, spam, resale, creation of parallel databases, to name
>> just a few reasons.
>>
>>
>>
>> Am 17.05.2017 um 18:02 schrieb Greg Shatan:
>>> Why do we want to prevent harvesting? Asking for a friend.
>>>
>>> *Greg Shatan
>>> *C: 917-816-6428
>>> S: gsshatan
>>> gregshatanipc at gmail.com <mailto:gregshatanipc at gmail.com>
>>>
>>>
>>> On Wed, May 17, 2017 at 11:58 AM, Volker Greimann
>>> <vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>> wrote:
>>>
>>> I can see dozens of legitimate reasons for restricting access that
>>> are not related to the efficiencies of the data retrieval system,
>>> first of which is harvesting prevention.
>>>
>>> Volker
>>>
>>>
>>> Am 17.05.2017 um 17:55 schrieb Paul Keating:
>>>> */³There must be no RDS policies that prevent RDS operators from
>>>> applying operational controls such as rate limiting and CAPTCHA,
>>>> provided that they do not unreasonably restrict legitimate
>>>> access.³/*,
>>>>
>>>> Caveat. The rate controls must be related to controlling the
>>>> efficiiciencies of the underlying data retrieval system and not
>>>> for o there purposes.
>>>>
>>>> PRK
>>>> From: <gnso-rds-pdp-wg-bounces at icann.org
>>>> <mailto:gnso-rds-pdp-wg-bounces at icann.org>> on behalf of Amr
>>>> Elsadr <amr.elsadr at icann.org <mailto:amr.elsadr at icann.org>>
>>>> Date: Wednesday, May 17, 2017 at 9:48 AM
>>>> To: "gnso-rds-pdp-wg at icann.org
>>>> <mailto:gnso-rds-pdp-wg at icann.org>" <gnso-rds-pdp-wg at icann.org
>>>> <mailto:gnso-rds-pdp-wg at icann.org>>
>>>> Subject: [gnso-rds-pdp-wg] IMPROTANT - Action Items and Notes
>>>> from Next-Generation RDS PDP Working Group Call - 17 May 2017
>>>>
>>>> Dear Working Group Members,
>>>>
>>>>
>>>>
>>>> Please find below the action items and notes from today¹s
>>>> Working Group call.
>>>>
>>>>
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>> Amr
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> /These high-level notes are designed to help PDP WG members
>>>> navigate through the content of the call and are not meant as
>>>> a substitute for the transcript and/or recording. The MP3,
>>>> transcript, and chat are provided separately and are posted
>>>> on the wiki here: https://community.icann.org/x/HMPRAw
>>>> <https://community.icann.org/x/HMPRAw>/
>>>>
>>>> / /
>>>>
>>>> *Action Items:*
>>>>
>>>>
>>>>
>>>> 1. Newcomers to RSVP to Newcomer Tutorial invitation if you
>>>> plan to attend
>>>>
>>>> 2. Staff to launch poll the test revised item 2) in statement
>>>> of purpose
>>>>
>>>><https://community.icann.org/download/attachments/56986791/KeyConceptsD
>>>>eliberation-WorkingDraft-9May2017.pdf?version=1&modificationDate=149437
>>>>2838376&api=v2>
>>>> and revised 2 May agreement:
>>>>
>>>> a. The test revised item 2) in statement of purpose
>>>>
>>>><https://community.icann.org/download/attachments/56986791/KeyConceptsD
>>>>eliberation-WorkingDraft-9May2017.pdf?version=1&modificationDate=149437
>>>>2838376&api=v2>:
>>>> "2) A purpose of RDS is to facilitate dissemination of gTLD
>>>> registration data of record, such as domain names and their
>>>> domain contacts and name servers, in accordance with
>>>> applicable policy.²
>>>>
>>>> b. Revised 2 May agreement: "gTLD registration "thin data"
>>>> must be accessible without requestor identification,
>>>> authentication, or stated purpose"
>>>>
>>>> WG members to participate in poll by COB Saturday 20 May.
>>>>
>>>> 3. Rod Rasmussen and Vaibhav Aggarwal to work together to
>>>> define what "unreasonably restrict legitimate access" means
>>>> in the context of this statement */³There must be no RDS
>>>> policies that prevent RDS operators from applying operational
>>>> controls such as rate limiting and CAPTCHA, provided that
>>>> they do not unreasonably restrict legitimate access.³/*, and
>>>> propose that definition to WG mailing list, preferably before
>>>> next week's WG call
>>>>
>>>>
>>>>
>>>> *Notes:*
>>>>
>>>>
>>>>
>>>> 1) Roll Call/SOI Updates
>>>>
>>>> * Attendance will be taken from AC
>>>> * Please remember to state your name before speaking and
>>>> remember to mute your microphones when not speaking
>>>> * SOI updates: none
>>>>
>>>> 2) Brief updates
>>>> a) Newcomer tutorial plans:
>>>>
>>>> * Tuesday 23 May, immediately following WG Call
>>>> * Recording to be available for on-demand replay
>>>>
>>>> *Action Item:* Newcomers to RSVP to Newcomer Tutorial
>>>> invitation if you plan to attend
>>>>
>>>> b) ICANN59 meeting plans:
>>>>
>>>> * Monday 26 June Cross-Community Session on RDS
>>>> * Tuesday 27 June Face-to-Face RDS PDP WG Session
>>>>
>>>> 3) Review proposed-final definition(s) to replace
>>>> "authoritative" in Statement of Purpose, Item 2):
>>>>
>>>> *
>>>>https://community.icann.org/download/attachments/64078620/DataOfRecord-
>>>>Proposal.pdf
>>>>
>>>><https://community.icann.org/download/attachments/64078620/DataOfRecord
>>>>-Proposal.pdf>
>>>> * Recommendation on how to proceed with replacement term
>>>> for "authoritative"
>>>> * Starting with poll results from 28 March for Statement of
>>>> Purpose item 2) - substitute term "Data of Record" so
>>>> that item will read:
>>>> * "2) A purpose of RDS is to facilitate dissemination of
>>>> gTLD registration data of record, such as domain names
>>>> and their domain contacts and name servers, in accordance
>>>> with applicable policy.²
>>>> * Definition: "the data set at a given time relevant to a
>>>> given registration object that expresses the data
>>>> provided in the then-current registration for that
>>>>object.²
>>>> * Can still later consider "source of record" but does not
>>>> appear needed to convey intent of this item in the
>>>> statement of purpose
>>>>
>>>> *Proposed WG Agreement (to test with poll): *"2) A purpose of
>>>> RDS is to facilitate dissemination of gTLD registration data
>>>> of record, such as domain names and their domain contacts and
>>>> name servers, in accordance with applicable policy.²
>>>> (including footnoted definition above)
>>>>
>>>> 4) Continue deliberation on the charter question 5: What
>>>> steps should be taken to control "thin data" access?
>>>>
>>>> * See
>>>> handout
>>>>https://community.icann.org/download/attachments/64078620/Charter%20Que
>>>>stion%205%20-%20Handout%20-%20For17MayCall%20v2.pdf
>>>>
>>>><https://community.icann.org/download/attachments/64078620/Charter%20Qu
>>>>estion%205%20-%20Handout%20-%20For17MayCall%20v2.pdf>
>>>> * Full results available
>>>> at
>>>>https://community.icann.org/download/attachments/64078620/SummaryResult
>>>>s-Poll-from-9MayCall.pdf
>>>>
>>>><https://community.icann.org/download/attachments/64078620/SummaryResul
>>>>ts-Poll-from-9MayCall.pdf>
>>>>
>>>> a) Is "thin data" access authentication required or allowed?
>>>>
>>>> * Proposed answer: Based on Poll Question 2) Option e)
>>>> * "Thin data elements must be accessible without requestor
>>>> authentication."
>>>> * With 33 responses, option e) had greatest support and
>>>> least opposition - but not rough consensus
>>>> * Does "inquirers identifying themselves" or
>>>> "authentication" imply a person rather than a machine
>>>> making the request?
>>>> * First proposed change "gTLD registration "thin data"
>>>> should be accessible without inquirer identification or
>>>> stating purpose".
>>>> * Consider combining option e) with this agreement, and
>>>> using "requestor" instead of "inquirer" for consistency
>>>> * Revised/combined proposed change "gTLD registration "thin
>>>> data" must be accessible without requestor
>>>> identification, authentication, or stated purpose".
>>>>
>>>> *Proposed WG Agreement (to test with poll):* "gTLD
>>>> registration "thin data" must be accessible without requestor
>>>> identification, authentication, or stated purpose".
>>>>
>>>> b) Is "thin data" access anonymity required or allowed?
>>>>
>>>> * Proposed answer: Based on Poll Question 2) Comment 9:
>>>> * "Access to thin registration data must be provided to
>>>> anonymous requestors."
>>>> * Does anyone think we must refer to anonymity or is
>>>> proposed agreement in a) sufficient?
>>>> * Introduces a new term that may be problematic.
>>>> * Why do we need to define anonymous now? Thick data for
>>>> LEA we may need to define anonymous and untraceable and a
>>>> whole slew of things but we are only on thin data now,
>>>>right?
>>>> * The current proposal (under a above) says what the
>>>> requestor does _not_ have to give, rather than trying to
>>>> create an attribute of the requestor
>>>>
>>>> c) Do we need to define "authentication"?
>>>>
>>>> * We might need to define it later (since we say that there
>>>> is no authentification required for thin data) - may need
>>>> to define it for thick data
>>>> * Is "according to policy" implicit in WG agreements? We
>>>> haven't yet agreed on specific "thin data" elements yet
>>>>
>>>> *Action Item:* Staff to launch poll the test revised item 2)
>>>> in statement of purpose and revised 2 May agreement (the two
>>>> Proposed WG Agreements above). WG members to participate in
>>>> poll by COB Saturday 20 May.
>>>>
>>>> d) Should policies allow or prevent application of
>>>> operational controls?
>>>>
>>>> * Rough consensus WG Agreement (75%) on Poll Question 3):
>>>> * /"There must be no RDS policies that prevent RDS
>>>> operators from applying operational controls such as rate
>>>> limiting and CAPTCHA, provided that they do not
>>>> unreasonably restrict legitimate access."/
>>>> * Need to define specific policy for "reasonable" and
>>>> "legitimate" during Phase 2 of this PDP?
>>>> * Is there a need for an explicit statement like this? If
>>>> the information is public, is it necessary to limit to
>>>> prevent scraping? Or is rate limiting being used to limit
>>>> legitimate access - can't ignore this gaming/artificial
>>>> limit possibility.
>>>> * Note 2013 RAA 3.3.5 states "Registrar shall permit use of
>>>> data it provides in response to queries for any lawful
>>>> purposes except to...(b) enable high volume, automated,
>>>> electronic processes that send queries or data to the
>>>> systems of any Registry Operator or ICANN-Accredited
>>>> registrar, except as reasonably necessary to register
>>>> domain names or modify existing registrations."
>>>> * Perhaps rather than saying something about rate-limiting
>>>> per se, we need an SLA about the level of access that
>>>> must be supported.
>>>> * Remaining silent on this point may lead to policies that
>>>> interfere with use of operational controls - but using
>>>> "unreasonably restrict legitimate access" may leap this
>>>> too open ended
>>>> * Agreed to put this rough consensus point on hold, pending
>>>> definition of what "unreasonably restrict legitimate
>>>> access" means
>>>>
>>>> *Action Item:* Rod Rasmussen and Vaibhav Aggarwal to work
>>>> together to define what "unreasonably restrict legitimate
>>>> access" means in the context of this statement and propose
>>>> that definition to WG mailing list, preferrably before next
>>>> week's WG call.
>>>>
>>>> e) Review all of charter question 5 sub-questions with goal
>>>> to complete first pass deliberation on "thin data" access in
>>>>May
>>>>
>>>> * DEFERRED TO 23 MAY WG MEETING
>>>>
>>>> 5) Confirm action items and proposed decision points
>>>>
>>>> * *Proposed WG Agreement (to test with poll): *"2) A
>>>> purpose of RDS is to facilitate dissemination of gTLD
>>>> registration data of record, such as domain names and
>>>> their domain contacts and name servers, in accordance
>>>> with applicable policy.² (including footnoted definition
>>>> above)
>>>> * *Proposed WG Agreement (to test with poll):* "gTLD
>>>> registration "thin data" must be accessible without
>>>> requestor identification, authentication, or stated
>>>>purpose".
>>>> * *Action Item:* Newcomers to RSVP to Newcomer Tutorial
>>>> invitation if you plan to attend
>>>> * *Action Item:* Staff to launch poll the test revised item
>>>> 2) in statement of purpose and revised 2 May agreement
>>>> (the two Proposed WG Agreements above). WG members to
>>>> participate in poll by COB Saturday 20 May.
>>>> * *Action Item:* Rod Rasmussen and Vaibhav Aggarwal to work
>>>> together to define what "unreasonably restrict legitimate
>>>> access" means in the context of this statement and
>>>> propose that definition to WG mailing list, preferably
>>>> before next week's WG call.
>>>>
>>>> 6) Confirm next meeting date: 23 May 2017 at 16:00 UTC
>>>>
>>>>
>>>>
>>>> *Meeting Materials*
>>>>
>>>> * *Data of Record Proposal
>>>>
>>>><https://community.icann.org/download/attachments/64078620/DataOfRecord
>>>>-Proposal.pdf?version=1&modificationDate=1494989338000&api=v2>*
>>>> * *Charter Question 5 - Handout - For17MayCall.pdf
>>>>
>>>><https://community.icann.org/download/attachments/64078620/Charter%20Qu
>>>>estion%205%20-%20Handout%20-%20For17MayCall%20v2.pdf?version=1&modifica
>>>>tionDate=1494961615000&api=v2>*
>>>> * *KeyConceptsDeliberation-WorkingDraft-9May2017.pdf
>>>>
>>>><https://community.icann.org/download/attachments/56986791/KeyConceptsD
>>>>eliberation-WorkingDraft-9May2017.pdf?version=1&modificationDate=149437
>>>>2838376&api=v2> *and *doc
>>>>
>>>><https://community.icann.org/download/attachments/56986791/KeyConceptsD
>>>>eliberation-WorkingDraft-9May2017.docx?version=1&modificationDate=14943
>>>>72853897&api=v2>*
>>>>
>>>> * *9 May Call Poll Results -*
>>>> o PDF of Poll Questions:* /Poll-from-9MayCall.pdf
>>>>
>>>><https://community.icann.org/download/attachments/64078610/Poll-from-9M
>>>>ayCall.pdf?version=1&modificationDate=1494374689000&api=v2>/*
>>>> o SurveyMonkey Summary Poll
>>>> Results: */SummaryResults-Poll-from-9MayCall.pdf
>>>>
>>>><https://community.icann.org/download/attachments/64078620/SummaryResul
>>>>ts-Poll-from-9MayCall.pdf?version=1&modificationDate=1494787660000&api=
>>>>v2>/*
>>>> o SurveyMonkey Raw Data Poll
>>>> Results: */RawDataResults-Poll-from-9MayCall.zip
>>>>
>>>><https://community.icann.org/download/attachments/64078620/RawDataResul
>>>>ts-Poll-from-9MayCall.zip?version=1&modificationDate=1494787676000&api=
>>>>v2>/* and */XLS
>>>>
>>>><https://community.icann.org/download/attachments/64078620/RawDataResul
>>>>ts-Poll-from-9MayCall.xls?version=1&modificationDate=1494787693000&api=
>>>>v2>/*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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>
>>>
>>> --
>>> 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>
>>>
>> --
>> 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
>>
>
>
>
>--
>"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
>https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
More information about the gnso-rds-pdp-wg
mailing list