[Gnso-ppsai-pdp-wg] PPSAI - Proposed language on attestation - a few new words

Graeme Bunton gbunton at tucows.com
Fri Apr 10 20:19:35 UTC 2015


Thanks Kathy,

Originally, I had concerns about this, similar to what Michele was 
expressing on the call.

In talking with our compliance team, it sounds like they have,  for a 
new or unknown requester that's a third party, attempted to verify the 
relationship between them and the rights holder.

The below language seems reasonable to me, and I wouldn't think it would 
generate anything that doesn't already exist.  Having it available may 
even make requests more efficient.

Graeme



On 2015-04-10 3:14 PM, Kathy Kleiman wrote:
>
> Hi Todd and All,
>
> It sounds like we all agree that the requester must have the rights 
> holders' authorization to make the submit the reveal request, make the 
> infringement allegation and bind the rights holder to the limitations 
> on the revealed data. For rights holders, that agency will be 
> reflected in a document -- an agency agreement (or equivalent). That's 
> all we're asking for -- the ability to see it if there are questions.  
> We circulated some longer language earlier, but have been reviewing 
> it. Building on Val's language, it may now boil down to a few 
> additional words. They are below (in italics) and attached in the 
> Reveal Policy (using the text by Mary for our meeting last Tues):
>
> -----------------------------------------------
>
>
> (1)               A good faith statement[, either] under penalty of 
> perjury [or notarized or accompanied by sworn statement[1] 
> (“Versicherung an Eides statt”),] from either the trademark holder or 
> an authorized representative of the trademark holder, that —:
>    a)                  provides a basis for reasonably believing that 
> the use of the trademark in the domain name
>                         (i)                 allegedly infringes the 
> trademark holder’s rights and
>                         (ii)               is not defensible;
>    b)                 states that Requestor will use Customer’s 
> contact details only
>                         (i)                 to determine whether 
> further action is warranted to resolve the issue;
>                         (ii)               to attempt to contact 
> Customer regarding the issue; and/or
>                         (iii)             in a legal proceeding 
> concerning the issue.
>
>     c)         Where the signatory is not the rights holder, he/she 
> must attest that he/she is an authorized representative of the rights 
> holder, capable and qualified to evaluate and address the matters 
> involved in this request, and having the                 authority to 
> make the representations and claims on behalf of the rights holder in 
> the request /including to bind the rights holder to the limitations on 
> the data once revealed[/2].
>
> /    d) //Where the signatory is not the rights holder, an officer of 
> the rights holder (if a corporate entity) or an attorney of the rights 
> holder, the signatory shall agree to provide a copy of its agency 
> agreement (or equivalent thereof) to the                    Provider 
> if requested.
>
> ----------------------------------------------------------
> /
> Best,
> Kathy
>
> On 4/10/2015 9:33 AM, Williams, Todd wrote:
>>
>> Thanks Volker.
>>
>> The whole point of the attestation language is for the requester to 
>> attest that they have the prop0er authorization, so that the P/P 
>> Provider can then rely on that attestation. Nobody is arguing that a 
>> requester should be able to submit a request without doing so.
>>
>> Rather, the only question on the table is whether the requester 
>> */also/* needs to provide documentation to the P/P Provider to “back 
>> up” that attestation – and if so, what form that documentation should 
>> take, and what steps the P/P Provider will need to take to validate 
>> it.  Here’s what Michele said on our call on Tuesday on that question:
>>
>> “For us as a provider of any service having to go off and validate 
>> third party documents is going to cost me money, time, effort, legal 
>> fees.  So I personally wouldn’t be interested in going down that route.”
>>
>> And then Volker here’s what you said:
>>
>> “Personally I would love to look at those contracts but not as a 
>> provider but rather as the curious cat that I am.  As a provider I 
>> would not want to see those contracts and the specific details, I 
>> just would like to see */a confirmation as part of the complaint/* 
>> that a certain standard has been followed and that would be of course 
>> also attributable to the complainant */but I wouldn't look at the 
>> contract as a provider/*.”
>>
>> (Emphasis added).
>>
>> But then in your email below you seem to be arguing the opposite.  So 
>> I guess I’m confused on where you stand on this.  Do you want the 
>> requester to have to provide documentation in support of its 
>> attestation that the P/P Provider will then be obligated to legally 
>> validate?  Or is it enough that the requester “confirm” (attest) as 
>> part of the complaint that a certain standard has been followed?
>>
>> -----Original Message-----
>> From: gnso-ppsai-pdp-wg-bounces at icann.org 
>> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Volker Greimann
>> Sent: Friday, April 10, 2015 4:32 AM
>> To: Alex_Deacon at mpaa.org; Kiran.Malancharuvil at markmonitor.com
>> Cc: gnso-ppsai-pdp-wg at icann.org
>> Subject: Re: [Gnso-ppsai-pdp-wg] PPSAI - Proposed language on attestation
>>
>> So you are proposing to move back into the realm of unsubstantiated 
>> claims? If we cannot even rely on the proper authorization of the 
>> agent, what can we rely on?
>>
>> And where is the harm in documenting the authority of the agent? The 
>> only cases where I see an issue is where there is no proper 
>> authorization and those should be excluded in the first place. So 
>> providing a PoA should really be a basic requirement.
>>
>> I really do not understand the issues with it.
>>
>> As to Privacy vs human rights: Privacy is the service. If a 
>> complainant only makes claims in order to remove the privacy, i.e. 
>> uses them as pretext, the request should be denied and the 
>> complainant ashamed of himself. Human rights on the other hand would 
>> require a detailed legal analysis. Also, Harm resulting from a denial 
>> of privacy not necessarily impacts human rights.
>>
>> Best,
>>
>> Volker
>>
>> Am 10.04.2015 um 00:50 schrieb Alex_Deacon at mpaa.org 
>> <mailto:Alex_Deacon at mpaa.org>:
>>
>> > Hi All,
>>
>> >
>>
>> > Just wanted to add my thoughts to this thread.
>>
>> >
>>
>> > Regarding attestation I support the language Val suggested at the 
>> beginning of this thread. Requiring a power-of-attorney or a half 
>> page authorization and attestation is unnecessary - especially if it 
>> neither has to be delivered to the Provider nor checked, verified or 
>> confirmed by the Provider.
>>
>> >
>>
>> > As for III.C.5, I’m not 100% sure where we landed but I believe 
>> that ending that sentence (the pretext provision) with “privacy” is 
>> not the way to go.  I am however OK with using “human rights (e.g., 
>> freedom of expression)”.  We don’t want to get into a situation where 
>> the mere request for a disclosure is always countered as 
>> “contravening” privacy and thus a basis to refuse all 
>> reveal/disclosure requests.
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> > Alex
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > On 4/8/15, 7:38 AM, "Volker Greimann" <vgreimann at key-systems.net 
>> <mailto:vgreimann at key-systems.net>> wrote:
>>
>> >
>>
>> >> Hi Kiran,
>>
>> >>
>>
>> >> it can be a general PoA but a PoA should be provided.
>>
>> >>
>>
>> >> Every lawyer making a legal request in Germany must, upon request,
>>
>> >> provide a copy of his PoA to the requestee. Providing documentary
>>
>> >> evidence of your authorization is also just good practice. How else
>>
>> >> is a recipient of a complaint to know the agent is properly
>>
>> >> authorized by the complainant?
>>
>> >>
>>
>> >> Best,
>>
>> >>
>>
>> >> Volker
>>
>> >>
>>
>> >> Am 08.04.2015 um 16:32 schrieb Kiran Malancharuvil:
>>
>> >>> To your first comment, the distinction between a registrar and a 
>> requesting party is best dealt with in Todd's email and Steve's.
>>
>> >>>
>>
>> >>> To your second, we are not going to complete and attach a power 
>> of attorney to every request.
>>
>> >>>
>>
>> >>> Thanks,
>>
>> >>>
>>
>> >>> Kiran
>>
>> >>>
>>
>> >>> Kiran Malancharuvil
>>
>> >>> Internet Policy Counselor
>>
>> >>> MarkMonitor
>>
>> >>> 415-419-9138 (m)
>>
>> >>>
>>
>> >>> Sent from my mobile, please excuse any typos.
>>
>> >>>
>>
>> >>>> On Apr 8, 2015, at 7:24 AM, Volker Greimann 
>> <vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>> wrote:
>>
>> >>>>
>>
>> >>>> Hi Kiran,
>>
>> >>>>
>>
>> >>>>> I have no interest in language that inserts itself into the 
>> relationship/authority under which we act on behalf of our clients.
>>
>> >>>> As a registrar, I know this very feeling very well. But such is 
>> life...
>>
>> >>>>> Further, I don't understand why it's necessary. The agent binds 
>> the trademark owner and consequently the owner liable for any 
>> negative consequences of the agents (potentially - very unlikely) 
>> abusive request on their behalf. If there is some breakdown of the 
>> agency relationship, or its misrepresented, the requestor is liable. 
>> Either way there is someone to punish.
>>
>> >>>> I think the details can be worked out. Personally, I could live 
>> with the complainant including a power of attorney in the complaint 
>> attachments which would include the required language.
>>
>> >>>>
>>
>> >>>> Volker
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>> K
>>
>> >>>>>
>>
>> >>>>> Kiran Malancharuvil
>>
>> >>>>> Internet Policy Counselor
>>
>> >>>>> MarkMonitor
>>
>> >>>>> 415-419-9138 (m)
>>
>> >>>>>
>>
>> >>>>> Sent from my mobile, please excuse any typos.
>>
>> >>>>>
>>
>> >>>>> On Apr 8, 2015, at 7:08 AM, Williams, Todd 
>> <Todd.Williams at turner.com<mailto:Todd.Williams at turner.com 
>> <mailto:Todd.Williams at turner.com%3cmailto:Todd.Williams at turner.com>>> 
>> wrote:
>>
>> >>>>>
>>
>> >>>>> Thank you Volker.  Yes, of course, I agree with all of that.  
>> And if we want to say that dotting the “i”s and crossing the “t”s in 
>> this context means including Val’s attestation language – such that a 
>> contracted party can ignore a complaint that doesn’t do that – I’m 
>> fine with that.
>>
>> >>>>>
>>
>> >>>>> But I don’t think that’s what we’re talking about.  We’re 
>> talking about what form the document that delegates authority from 
>> the trademark/copyright owner to third-party agents should take, and 
>> who must sign it.  But if the contracted party isn’t going to have to 
>> check, verify, or confirm that form (and I don’t think there is any 
>> way they can, for the reasons that you and Michele mentioned 
>> yesterday), and in fact may never see it, that’s where I get confused.
>>
>> >>>>>
>>
>> >>>>> From:
>>
>> >>>>> 
>> gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounc 
>> <mailto:gnso-ppsai-pdp-wg-bounces at icann.org%3cmailto:gnso-ppsai-pdp-wg-bounc>
>>
>> >>>>> es at icann.org <mailto:es at icann.org>> 
>> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On
>>
>> >>>>> Behalf Of Volker Greimann
>>
>> >>>>> Sent: Wednesday, April 08, 2015 9:53 AM
>>
>> >>>>> To:
>>
>> >>>>> gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org 
>> <mailto:gnso-ppsai-pdp-wg at icann.org%3cmailto:gnso-ppsai-pdp-wg at icann.org>>
>>
>> >>>>> Subject: Re: [Gnso-ppsai-pdp-wg] PPSAI - Proposed language on
>>
>> >>>>> attestation
>>
>> >>>>>
>>
>> >>>>> Hi Todd,
>>
>> >>>>>
>>
>> >>>>> it fits the remit only if that becomes a trigger for a reveal 
>> process, i.e. ifconditions a, b, and c are met and d, e, and f are 
>> not present, g follows.
>>
>> >>>>>
>>
>> >>>>> ICANN cannot tell third parties what to do. But it can tell a 
>> contracted party what they must accept and what they can ignore. And 
>> if a request does not meet the requirements, no obligation of the 
>> provider to act in a certain way is triggered.
>>
>> >>>>>
>>
>> >>>>> In other words, if the complainant dots the "i"s and crosses 
>> the "t"s, inaction by the provider could result in compliance action. 
>> If the complainant does not care to follow prescribed procedure, 
>> nothing the provider does results in compliance action.
>>
>> >>>>>
>>
>> >>>>> Volker
>>
>> >>>>>
>>
>> >>>>> Am 08.04.2015 um 15:29 schrieb Williams, Todd:
>>
>> >>>>> I’m sorry, I’m getting quite confused on this part.
>>
>> >>>>>
>>
>> >>>>> Ultimately what we’re discussing is an accreditation policy for 
>> P/P Providers, correct?  And one of the questions (the big question) 
>> that we’ve been discussing is when can/should/must accredited P/P 
>> Providers disclose?  We’ve developed a fairly detailed framework to 
>> answer that question (at least in the trademark and copyright 
>> context), and one component of that framework is that a request for 
>> disclosure must include the requisite attestation (and, for the 
>> record, I like Val’s language as to what that attestation should look 
>> like).  So far that all makes sense to me.
>>
>> >>>>>
>>
>> >>>>> But now we’re debating what form the document that delegates 
>> authority from the trademark/copyright owner to third-party agents 
>> should take (and who must sign it)?  As Paul mentioned: how does that 
>> fit into our remit?  It doesn’t have anything to do with the P/P 
>> providers whom ICANN will be accrediting – right?  As Kathy mentioned 
>> below, the forms will not “be delivered to the Provider and certainly 
>> not checked, verified or confirmed by the Provider.”  But if that’s 
>> the case – meaning that the P/P Provider is completely out of the 
>> loop – then how can ICANN regulate the content of that form (and who 
>> must sign it) by accrediting (or de-accrediting) a P/P Provider who 
>> has nothing to do with the form, isn’t checking, verifying, or 
>> confirming it, and in fact may never see it?  I guess I don’t see the 
>> contractual “hook” any more.
>>
>> >>>>>
>>
>> >>>>> To put it another way: the trademark/copyright owners have no 
>> contractual relationship with ICANN, right?  So how can ICANN tell 
>> them what form to use when they choose to delegate authority (and who 
>> must sign it)?  And when we say that the forms should be “available 
>> for audit” – audit by whom?  By ICANN?
>>
>> >>>>>
>>
>> >>>>> Bottom line: I would think that the most that we can do is 
>> perfect Val’s attestation language (and I like it the way that it 
>> is), and then leave it at that.  Does that mean that there is a risk 
>> that the attestation will be false in some cases?  Yes.  But can 
>> ICANN police false attestations through its contracting/accreditation 
>> of P/P Providers?  I don’t see how.
>>
>> >>>>>
>>
>> >>>>> From:
>>
>> >>>>> 
>> gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounc 
>> <mailto:gnso-ppsai-pdp-wg-bounces at icann.org%3cmailto:gnso-ppsai-pdp-wg-bounc>
>>
>> >>>>> es at icann.org <mailto:es at icann.org>> 
>> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On
>>
>> >>>>> Behalf Of Kathy Kleiman
>>
>> >>>>> Sent: Tuesday, April 07, 2015 3:24 PM
>>
>> >>>>> To: McGrady, Paul D.;
>>
>> >>>>> gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org 
>> <mailto:gnso-ppsai-pdp-wg at icann.org%3cmailto:gnso-ppsai-pdp-wg at icann.org>>
>>
>> >>>>> Subject: Re: [Gnso-ppsai-pdp-wg] PPSAI - Proposed language on
>>
>> >>>>> attestation
>>
>> >>>>>
>>
>> >>>>> Hi Paul, Hi Jim,
>>
>> >>>>> No, the proposal would not apply to attorneys. The proposal is 
>> designed to apply to consultants and other outside entities not bound 
>> by the attorney-client relationship. We'll be certain to clarify in 
>> the next version. But tracing back to our discussions over the last 
>> few weeks -- we have been concerned about parties *other than 
>> attorneys and officers of the company* making legal allegations and 
>> taking possession of private data.  By the rules we live by, 
>> attorneys for the company (inside and outside counsel) and officers 
>> of the corporation are bound by a number of ethical and fiduciary 
>> rules (depending on their position) that help ensure that they will 
>> operate a) within the scope of their expertise in making legal 
>> allegations of infringement and b) within the scope of their 
>> authority to legally bind their companies to the limitations that the 
>> policy will require for the use of the revealed data.
>>
>> >>>>>
>>
>> >>>>> What we are looking for is some documentation from the 
>> Trademark Owner/Copyright Owner that consultants and others similarly 
>> have a) the expertise to make the legal allegations of infringement, 
>> and b) have the legal authority to bind Procter & Gamble and others 
>> to limitations on the use of the revealed data once received.
>>
>> >>>>>
>>
>> >>>>> The half page authorization and delegation to the consultant on 
>> letterhead from the Trademark Owner/Copyright Owner that I think 
>> Chris Pelling spoke of today would probably complement Val's 
>> self-attestation terms nicely. It does not have to be delivered to 
>> the Provider and certainly not checked, verified or confirmed by the 
>> Provider, but it should be available for audit. And again, applies to 
>> those not bound by the other rules we have discussed...
>>
>> >>>>>
>>
>> >>>>> Best,
>>
>> >>>>> Kathy
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> :
>>
>> >>>>> Kathy, would you proposal below apply to law firms as well?  I 
>> will let the other service providers speak for themselves, but I 
>> really, really don’t think ICANN has any business attempting to 
>> interfere in attorney/client relationships – that is clearly outside 
>> of our scope and ICANN’s remit.
>>
>> >>>>>
>>
>> >>>>> Best,
>>
>> >>>>> Paul
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> Paul D. McGrady Jr.
>>
>> >>>>>
>>
>> >>>>> Partner
>>
>> >>>>>
>>
>> >>>>> Chair, Trademark, Domain Names and Brand Enforcement Practice
>>
>> >>>>>
>>
>> >>>>> Winston & Strawn LLP
>>
>> >>>>> 35 W. Wacker Drive
>>
>> >>>>> Chicago, IL 60601-9703
>>
>> >>>>>
>>
>> >>>>> D: +1 (312) 558-5963
>>
>> >>>>>
>>
>> >>>>> F: +1 (312) 558-5700
>>
>> >>>>>
>>
>> >>>>> Bio<http://www.winston.com/en/who-we-are/attorneys/mcgrady-paul-d.
>>
>> >>>>> html> | VCard<http://www.winston.com/vcards/996.vcf> |
>>
>> >>>>> Email<mailto:pmcgrady at winston.com> |
>>
>> >>>>> winston.com<http://www.winston.com>
>>
>> >>>>>
>>
>> >>>>> <image001.jpg>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> From:
>>
>> >>>>> 
>> gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounc 
>> <mailto:gnso-ppsai-pdp-wg-bounces at icann.org%3cmailto:gnso-ppsai-pdp-wg-bounc>
>>
>> >>>>> es at icann.org <mailto:es at icann.org>> 
>> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On
>>
>> >>>>> Behalf Of Kathy Kleiman
>>
>> >>>>> Sent: Tuesday, April 07, 2015 8:19 AM
>>
>> >>>>> To:
>>
>> >>>>> gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org 
>> <mailto:gnso-ppsai-pdp-wg at icann.org%3cmailto:gnso-ppsai-pdp-wg at icann.org>>
>>
>> >>>>> Subject: Re: [Gnso-ppsai-pdp-wg] PPSAI - Proposed language on
>>
>> >>>>> attestation
>>
>> >>>>>
>>
>> >>>>> Tx Val,
>>
>> >>>>> Many of us think adding the statement you have drafted below 
>> would be very useful.  Tx you! But still it does not get its hand 
>> around our full concer. What we seek is not the self-declaration of 
>> the Consultant, but the clear delegation of the Trademark/Copyright 
>> Owner (e.g., Procter and Gamble). Where is the authorization?
>>
>> >>>>>
>>
>> >>>>> James Gannon, our newest member, has been working on some 
>> language that is perhaps a little long, and I am sure we can 
>> consolidate, but creates a "Letter of Delegation of Authority for 
>> Reveal Requests" that shows clearly that the Trademark/Copyright 
>> Owner at the senior levels intended to delegate the authority for the 
>> legal judgments of infringements being made, and the limitations on 
>> the use of the revealed data being committed to. Provided to the 
>> Provider and, if necessary, the Customer.
>>
>> >>>>>
>>
>> >>>>> Here's the language. Best, Kathy
>>
>> >>>>> ------------------------------------------------------------------
>>
>> >>>>> --------------------------------------------------
>>
>> >>>>>
>>
>> >>>>> In order to find a compromise between both sides of the aisle 
>> here I suggest the following possible solution:
>>
>> >>>>>
>>
>> >>>>> Policy Principle: Entities who issue requests pursuant to the 
>> Policy must ensure they have the delegated authority to do so. Where 
>> an entity requests a reveal of records and does not have the written 
>> authority to do so, the entity is deemed to be in non-compliance with 
>> the policy.
>>
>> >>>>>
>>
>> >>>>> Detailed Policy Language for Principle:
>>
>> >>>>>
>>
>> >>>>> The sitting corporate officers or general counsel of the 
>> requester organization issues a Letter of Delegation of Authority for 
>> Reveal Requests to be held directly by anyone to whom the Reveal 
>> Request authority is delegated.  This letter is separate to the 
>> general delegation of agency to work on the holders behalf. This 
>> letter would be specifically delegating the authority to issue Reveal 
>> Requests to P/P Service Providers.
>>
>> >>>>>
>>
>> >>>>> The letter would include the following provisions:
>>
>> >>>>>
>>
>> >>>>> - Confirming and warranting the authorization of the delegator 
>> to appoint a delegate as an sitting Officer or General Counsel of the 
>> company or entity in question.
>>
>> >>>>> - Specifying the nature of the delegation and the subject to 
>> whom the delegation is being given.
>>
>> >>>>>
>>
>> >>>>> - For each individual that the delegation of authority applies, 
>> a letter so delegating that authority to the individual, by name, 
>> will be prepared.  This letter will specify that the delegation is 
>> specific to the process for requesting reveals of personal and 
>> potentially private and sensitive information of individuals, 
>> organizations and companies.
>>
>> >>>>>
>>
>> >>>>> - Affirming the authority and expertise of the delegated party 
>> to render legal judgements on trademark and copyright infringements.
>>
>> >>>>>
>>
>> >>>>> - Clearly and directly affirming the commitment of the 
>> delegating organization or company to be bound by the limits of the 
>> use of the Revealed Data as set out in the ICANN policy now and as it 
>> might be modified in the future, and consistent with the laws of the 
>> jurisdiction in which the Proxy/Privacy Service Provider is incorporated.
>>
>> >>>>>
>>
>> >>>>> - Delegating Organization or Company expressly agrees to be 
>> answerable for any challenges that arise by virtue of the Delegatee's 
>> actions in preparing and responding to Reveal Requests, and the 
>> Delegatee's handling of the Revealed Data, and agrees to be bound to 
>> challenge, review and/or lawsuit in any jurisdiction in which the 
>> Delegatee has agreed to be bound.
>>
>> >>>>>
>>
>> >>>>> - Delegating Organization or Company consents Provide a copy of 
>> this Letter of Delegated Authority for Reveal Requests as a part of 
>> the Reveal Request process and as requested by the Proxy/Privacy 
>> Service Provider.
>>
>> >>>>> ---
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> :
>>
>> >>>>> Dear all:
>>
>> >>>>>
>>
>> >>>>> Following up on our productive discussion earlier this week, 
>> we’d like to offer a suggestion to modify the “attestation” 
>> provisions (II.A.6.c; II.B.7.d; and II.C.6.c) to require a statement 
>> by the requestor specifying his/her authority for making the request, 
>> or basis for agency if he or she is not the rights holder. For 
>> example: “Where the signatory is not the rights holder, he/she must 
>> attest that he/she is an authorized representative of the rights 
>> holder, capable and qualified to evaluate and address the matters 
>> involved in this request, and having the authority to make the 
>> representations and claims on behalf of the rights holder in the 
>> request.”
>>
>> >>>>>
>>
>> >>>>> We could even spell out the statement for the signatory to make 
>> in conjunction with each request : “I attest that I am the rights 
>> holder / authorized representative of the rights holder, capable and 
>> qualified to evaluate and address the matters involved in this 
>> request, and have the authority to make the representations and 
>> claims in this request.”
>>
>> >>>>>
>>
>> >>>>> These statements of authority and agency are to be made in good 
>> faith, under the penalty of perjury – just like representations 
>> forming the basis for the request and the requestor’s promise to use 
>> the data disclosed only for limited enumerated purposes – and the 
>> falsity of these statements would be redressable by the method(s) we 
>> agree on.
>>
>> >>>>>
>>
>> >>>>> We believe this approach fairly balances the considerations 
>> expressed by various WG members and look forward to your thoughts.
>>
>> >>>>>
>>
>> >>>>> Best,
>>
>> >>>>> Val
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> Valeriya
>>
>> >>>>> Sherman<http://www.sgrlaw.com/attorneys/profiles/sherman-valeriya/
>>
>> >>>>> > | Attorney at Law
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> 202-973-2611 phone
>>
>> >>>>> 202-263-4326 fax
>>
>> >>>>> www.sgrlaw.com<http://www.sgrlaw.com 
>> <http://www.sgrlaw.com%3chttp:/www.sgrlaw.com>>
>>
>> >>>>> vsherman at sgrlaw.com<mailto:vsherman at sgrlaw.com 
>> <mailto:vsherman at sgrlaw.com%3cmailto:vsherman at sgrlaw.com>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> 1055 Thomas Jefferson Street, N.W.
>>
>> >>>>> Suite 400
>>
>> >>>>> Washington, D.C. 20007
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> Ms. Sherman's practice is limited to matters before federal 
>> courts and before the United States Patent and Trademark Office.
>>
>> >>>>> She is not admitted in the District of Columbia.
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> <image002.jpg><http://www.sgrlaw.com> Smith, Gambrell & Russell,
>>
>> >>>>> LLP
>>
>> >>>>>
>>
>> >>>>> ________________________________
>>
>> >>>>> Confidentiality Notice
>>
>> >>>>> This message is being sent by or on behalf of a lawyer. It is 
>> intended exclusively for the individual or entity to which it is 
>> addressed. This communication may contain information that is 
>> proprietary, privileged or confidential or otherwise legally exempt 
>> from disclosure. If you are not the named addressee, you are not 
>> authorized to read, print, retain, copy or disseminate this message 
>> or any part of it. If you have received this message in error, please 
>> notify the sender immediately by e-mail and delete all copies of the 
>> message.
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> _______________________________________________
>>
>> >>>>>
>>
>> >>>>> Gnso-ppsai-pdp-wg mailing list
>>
>> >>>>>
>>
>> >>>>> Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org 
>> <mailto:Gnso-ppsai-pdp-wg at icann.org%3cmailto:Gnso-ppsai-pdp-wg at icann.org>>
>>
>> >>>>>
>>
>> >>>>> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> The contents of this message may be privileged and 
>> confidential. Therefore, if this message has been received in error, 
>> please delete it without reading it. Your receipt of this message is 
>> not intended to waive any applicable privilege. Please do not 
>> disseminate this message without the permission of the author.
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> _______________________________________________
>>
>> >>>>>
>>
>> >>>>> Gnso-ppsai-pdp-wg mailing list
>>
>> >>>>>
>>
>> >>>>> Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org 
>> <mailto:Gnso-ppsai-pdp-wg at icann.org%3cmailto:Gnso-ppsai-pdp-wg at icann.org>>
>>
>> >>>>>
>>
>> >>>>> https://mm.icann.org/mailman/listinfo/gnso-ppsai-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 
>> <mailto:vgreimann at key-systems.net%3cmailto:vgreimann at key-systems.net>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> Web: www.key-systems.net<http://www.key-systems.net 
>> <http://www.key-systems.net%3chttp:/www.key-systems.net>> /
>>
>> >>>>> www.RRPproxy.net<http://www.RRPproxy.net 
>> <http://www.RRPproxy.net%3chttp:/www.RRPproxy.net>>
>>
>> >>>>>
>>
>> >>>>> www.domaindiscount24.com<http://www.domaindiscount24.com 
>> <http://www.domaindiscount24.com%3chttp:/www.domaindiscount24.com>> /
>>
>> >>>>> www.BrandShelter.com<http://www.BrandShelter.com 
>> <http://www.BrandShelter.com%3chttp:/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%3chttp:/www.facebook.com/KeySystems>>
>>
>> >>>>>
>>
>> >>>>> www.twitter.com/key_systems<http://www.twitter.com/key_systems 
>> <http://www.twitter.com/key_systems%3chttp:/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%3chttp:/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%3cmailto:vgreimann at key-systems.net>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>>
>>
>> >>>>> Web: www.key-systems.net<http://www.key-systems.net 
>> <http://www.key-systems.net%3chttp:/www.key-systems.net>> /
>>
>> >>>>> www.RRPproxy.net<http://www.RRPproxy.net 
>> <http://www.RRPproxy.net%3chttp:/www.RRPproxy.net>>
>>
>> >>>>>
>>
>> >>>>> www.domaindiscount24.com<http://www.domaindiscount24.com 
>> <http://www.domaindiscount24.com%3chttp:/www.domaindiscount24.com>> /
>>
>> >>>>> www.BrandShelter.com<http://www.BrandShelter.com 
>> <http://www.BrandShelter.com%3chttp:/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%3chttp:/www.facebook.com/KeySystems>>
>>
>> >>>>>
>>
>> >>>>> www.twitter.com/key_systems<http://www.twitter.com/key_systems 
>> <http://www.twitter.com/key_systems%3chttp:/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%3chttp:/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-ppsai-pdp-wg mailing list
>>
>> >>>>> Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org 
>> <mailto:Gnso-ppsai-pdp-wg at icann.org%3cmailto:Gnso-ppsai-pdp-wg at icann.org>>
>>
>> >>>>> https://mm.icann.org/mailman/listinfo/gnso-ppsai-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.
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >> --
>>
>> >> 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-ppsai-pdp-wg mailing list
>>
>> >> Gnso-ppsai-pdp-wg at icann.org <mailto:Gnso-ppsai-pdp-wg at icann.org>
>>
>> >> https://mm.icann.org/mailman/listinfo/gnso-ppsai-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-ppsai-pdp-wg mailing list
>>
>> Gnso-ppsai-pdp-wg at icann.org <mailto:Gnso-ppsai-pdp-wg at icann.org>
>>
>> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>>
>>
>>
>> _______________________________________________
>> Gnso-ppsai-pdp-wg mailing list
>> Gnso-ppsai-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>
>
>
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing list
> Gnso-ppsai-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

-- 
_________________________
Graeme Bunton
Manager, Management Information Systems
Manager, Public Policy
Tucows Inc.
PH: 416 535 0123 ext 1634

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20150410/4a51ea2c/attachment-0001.html>


More information about the Gnso-ppsai-pdp-wg mailing list