RE: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow

["Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>]

Rick is right about the discussion of thick vs. thin.  It took place way before 
ICANN got involved.  In fact, the first thick registries (.biz and .info) 
voluntarily chose to be thick in their applications in 2000.  We chose this 
because we believed there was greater security in thick registries, better 
back-up (at a time when no registrar did data escrow), and help to the transfer 
process.  I believe it was built in some of the early models of EPP (which we 
called XRP back then) before it was a standard.

More trivia…back then it was called a politically incorrect “fat model” as 
opposed to “thick”.

From our .biz proposal in 2000 
(http://archive.icann.org/en/tlds/biz4/TechCapPlanBiz.htm):

“JVTeam proposes moving to a �fat registry� model, with contact and 
authentication details stored centrally at the Registry.� Under this model, the 
business relationships would be unchanged: registrants would still deal with 
the registrar, and the registrars with the registry.� The value of the proposed 
change is its ability to solve many of the problems currently experienced on a 
daily basis by both Registrants and Registrars.
As part of its fat-registry proposal, JVTeam proposes to introduce a new 
protocol, the eXtensible Registry Protocol (XRP), which will overcome the 
limitations of the current RRP protocol (RFC2832).� The XRP protocol will 
accommodate both thin and fat registry models.� We do not anticipate 
introducing the XRP protocol until after the �land rush� period has ended.”


III.2.2.1     �����Problems With The Current Model and its Supporting Protocol 
(RRP)
The current TLD is based on a thin registry model and the RRP protocol.� 
Problems with the system cause confusion for registrants and have added costs 
(and risk) to registrars because of the need for manual processing or the 
breakdown of automated processes.� The following table lists issues with the 
current model and RRP and gives example relating to these issues:
Deficiencies of the current registry/registrar model and protocol

Issue

Result

Protocol not extensible

• No ability to authenticate registrants
• Not designed for fat registry model
• Not designed using a naturally extensible technology, such as XML

Protocol not complete

• Not all data exposed (e.g., registrar details and status not exposed)
• No ability to query transfer status
• No date/time of registration and expiration
• No status on domains linked to another registrar

Different protocols used for Whois

• No uniform Whois standard (registrars can use web interface)
• Not all registrars use Whois on Port 43

No standard Whois fields

• Each registrar has implemented Whois differently.� Differences include:
• Some registrars have additional registrant contact information
• No standards exist for technical and/or zone contact
• Some registrars have one address line; others, two lines
• Some registrars don�t expose all fields in the Whois

Different data formatting in Whois services

• Data is presented differently; i.e., Phone: 99999 or Phone Number: (999) 999
• Different ordering of fields
• Different lengths of fields

No real-time update of Whois and zone file

• Registry updates Whois and root servers only every 12 hours
• Causes confusion for Registrants, adds support cost to Registrars

Timing inconsistencies (when adding, deleting, transferring registrar, etc)

• Registry Whois server updated before or after Registrar database, causing 
inconsistency between the two
• Two registrars� databases can be updated at different times, causing 
inconsistency

No machine-readable Whois format

• No automated parsing of Whois data by non-registrar community (Need XML-based 
Whois format)

No registrar extensibility

• No provisions for registrars to add custom fields to registry database except 
after revising the protocol

No ability to broadcast events to registrars

• Registry cannot automatically notify Registrars of important events (e.g., 
�Transfer of Registrar� request or renaming of a name server host name); must 
use email
• Cannot accommodate registrars� need to add �listeners� to certain important 
events

No registrant authentication

• Cannot determine whether a registrant�s �Transfer of Registrar� request is 
authentic.� The registrar must make a subjective decision about whether the 
registrant is the one represented in the losing Registrar�s Whois
• No standard method for authenticating deletions, changes of ownership, 
re-delegations, name-server maintenance, etc
• TLD security sinks lowest common (registrar) denominator, because a registrar 
with poor security could perform an incorrect Transfer of Registrar, giving the 
registrant control of the wrong domain name.� Potential for �hijacked� domain 
names creates huge stability problems to the Internet.

No rollback support for some operations

• Not all operations can be reversed by a separate counteraction (although some 
can: e.g.,� �Register domain name� can be reversed by �Cancel domain name� 
command within 5 days)
• Operations like Registrar Transfer cannot be �rolled-back� via the protocol 
in the case of error

No support for IPv6

• Does not support important, currently deployed technology

III.2.2.2     ����Features of the Fat Registry Model
As the beginning of this proposal paragraph (III.2.2) states, JVTeam proposes 
deploying a �fat registry� model, with contact and authentication details 
stored centrally at the Registry.� Exhibit III.2-7 illustrates the fat registry 
model.��
JVTeam prepared the following list of design features for our proposed XRP 
protocol:
• Extensible protocol based on XML
• Support for both fat and thin registry models
• Support for centralized contact information / centralized Whois
• Standardized Whois service (same fields regardless of registrar�s web site)
• Machine readable Whois format (when specified)

[131.ICANN]

• Extensible data-field support (registrars can add custom fields to Whois 
following standardized fields)
• Functionally complete (exposing all registry data via one interface)
• Secure
• Non-repudiation (No deniability)
• Fault tolerant (Duplicate requests have no adverse effect)
• Real-time XRP functions (check, register, etc)
• Real-time DNS and Whois updates
• Support for IPv6 IP addresses
• Standard, centralized registrant-authentication method
• Extensible registrant-authentication methods (support for digital 
certificates, etc)
• Simple account transfer (between registrars, using centralized authentication)
• Event broadcasting (ability for registrars to place �listeners� on registry 
events)
• Rollback support (i.e., rollback registrar transfer; not necessarily 
transactional).
JVTeam firmly believes that the industry needs a new extensible protocol that 
addresses all of the above points, and that the selected protocol should become 
the industry standard.� JVTeam�s position is that there is infinite room to 
innovate in many other aspects of domain-registry systems, but competition at 
the protocol level merely fragments the domain-name-registration industry.� 
Conversely, the industry will gain significantly in efficiency if it adopts a 
standard protocol that addresses the listed requirements, particularly in 
supporting both fat and thin Registry models.�
JVTeam�s proposed XRP protocol addresses each of the above points.� We will 
present a draft XRP to the IETF as the basis for an industry standard in Q4 
2000, and will invite comments and suggestions from registrars, registries, and 
other concerned individuals and organizations.� Rather than holding XRP as 
proprietary, we will undertake all reasonable measures to obtain consensus on 
making the proposed protocol an open industry standard.
III.2.2.3     �����Benefits of Proposed XRP Solution
JVTeam�s proposed XRP Solution and fat-registry model will preserve the current 
relationships that are familiar to both registrants and registrars.� 
Simultaneously, they will solve the many problems with the current RRP-based 
model that is raising costs for registrars and distressing registrants.�� 
Nonetheless, despite the fat-registry model�s obvious advantages, we are 
willing to consider alternatives.�
On the one hand it is theoretically possible retain the current thin-registry 
model and place more stringent technical requirements on registrars (while 
closely policing compliance). On the other hand, JVTeam believes that a more 
practical solution�the only solution that introduces true stability and domain 
security into the market�is moving to a fat-registry model with a new XML-based 
protocol that supports the many enhancements previously listed.� The XRP 
protocol�indeed, any new protocol�must be designed to fix all the problems with 
the current model and protocol.
To facilitate the transit in 2001 for current registrars, JVTeam will provide 
an open-source version of the registrar toolkit.� This enhanced toolkit will 
simplify the migration efforts of registrars that currently use the RRP toolkit 
only.
JVTeam is well qualified to take a lead position in the process of developing 
and standardizing the specification for a new protocol.� In preparing our 
proposal for building a modern, extensible protocol, we relied heavily on the 
extensive prior experience that Melbourne IT brought to JVTeam.� Research 
groups at Melbourne IT have been using XML for more than two years, and have 
developed two XML-based domain-name-registration interfaces.� Further, the 
company currently has XML-based interfaces in production.�

From:  http://archive.icann.org/en/tlds/biz4/TLDPolicyPropbiz.htm

How will complete, up-to-date, reliable, and conveniently provided Whois data 
be maintained, updated, and accessed concerning registrations in the TLD?

JVTeam plans to operate as a �fat� registry in that it will maintain all 
relevant databases for the registry in a centralized fashion.� This approach 
increases stability, security and fault tolerance of the registry.� JVTeam will 
backup and escrow all data to ensure its integrity.� The Whois database will be 
updated on a real-time basis and access will be provided subject to strict data 
privacy and security requirements.

In order to ensure up-to-date Whois data, included in the registrar Code of 
Conduct discussed above will be a provision requiring registrars to make �best 
commercial efforts� to maintain up-to-date registrant data.� In addition, 
JVTeam intends to explore with the registrars the development of a 3-month 
Whois data update reminder system.� Registrants would be asked every three 
months whether their Whois data remains accurate and would be provided with an 
update link if data were out of date.� Moreover, JVTeam will design the 
registration system to only complete a registration if all registration data is 
complete.

A more detailed discussion and description of Whois services can be found in 
Registry Operator�s Proposal Section III.2.8 of this proposal.


Jeffrey J. Neuman
Neustar, Inc. / Vice President, Business Affairs


From: owner-gnso-thickwhoispdp-wg@xxxxxxxxx 
[mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx] On Behalf Of Rick Wesson
Sent: Thursday, October 17, 2013 7:11 PM
To: Avri Doria
Cc: Thick Whois WG
Subject: Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow

Lets see, there was discussion about thick / thin for many years, first, in the 
IETF. Then during the development of EPP. Several new whois replacements were 
designed in the intervening years and that discussion to place mainly at ICANN 
events. Within the registrar community it was discussed and within the GNSO.

Certainly before deciding the color of the draperies became a PDP we discussed 
thick -vs- thin whois models from both a technical and privacy perspectives.

Just because you didn't participate back in 2002 does not mean the community 
didn't think about the issue. There was great discussion on the role of thick 
-vs- thin and how EPP would facilitate a thick registry.

remember, thick registries and EPP were an invention of the ICANN community. We 
thought a lot about it.

I feel your comments below ignore these facts and as such I have pressed 
DELETE. Thanks for playing ICANN trivia =)

-rick



On Thu, Oct 17, 2013 at 3:47 PM, Avri Doria <avri@xxxxxxx<mailto:avri@xxxxxxx>> 
wrote:
Hi,

I don't think we ever had that choice.  The board decided top-down style, that 
all new gTLDs would be thick.  There never was a PDP on that that I recall, it 
is just one of those things that were decided for us by the Board.  It 
certainly was not a recommendation made by the new gTLD program, but using the 
operational philosophy that if we didn't discuss it, they get to do what they 
wish, they decided all new gTLD MUST be thick.  So thick they will be.  This 
was one of the earliest instances of unilateral decisions with regard to new 
gTLDs to be made by the Board and Staff. (though the one to essentially exclude 
applicants from previous rounds from contesting without paying most of a new 
fee, probably precedes the thick decision.

This group has the choice of deciding whether incumbents need to become thick.

And this group, I beleive, was charter to discuss about the details of the 
thickness requirement for all gTLDs.

Personally I beleive that if this group had not decided to impose thickness on 
the incumbents, the Board and Sr. Staff would have overruled us and would have 
done it anyway.  But I can't prove that either.


avri



On 17 Oct 2013, at 02:34, Alan Greenberg wrote:

> Not quite how I understood it.
>
> I thought (and think) that we have a binary decision.
>
> 1. All gTLDs should be thick.
>
> 2. All gTLDs need not be thick.
>
> In the latter case, nothing would change today, and should we have a new 
> round of gTLDs, a decision would need to be made on thick vs thin if that 
> distinction is indeed still applicable.
>
> Alan
>
> At 16/10/2013 09:11 AM, Don Blumenthal wrote:
>> Rick,
>>
>> Thick registries for new gTLDs applies only to the current round, not any 
>> future open calls. Part of the WG's job was to examine if the requirement 
>> should carry forward.
>>
>> Don
>>
>> From: Rick Wesson < 
>> Rick@xxxxxxxxxxxxxxxxxxxxxxxx<mailto:Rick@xxxxxxxxxxxxxxxxxxxxxxxx>>
>> Date: Tuesday, October 15, 2013 7:30 PM
>> To: Amr Elsadr <aelsadr@xxxxxxxxxxx<mailto:aelsadr@xxxxxxxxxxx>>
>> Cc: Thick Thin PDP < 
>> gnso-thickwhoispdp-wg@xxxxxxxxx<mailto:gnso-thickwhoispdp-wg@xxxxxxxxx>>
>> Subject: Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow
>>
>> Amr
>>
>> All new gTLDs are thick by design. If you want to reexamine this, we would 
>> need to reexamine the ticck model which IMNSHO has been settled and is not 
>> within the scope of our current charter. We are to examin transition only.
>>
>> The data is published, the only relevant issue is the location of the entity 
>> doing the publishing.
>>
>> -rick
>>
>>
>>
>> On Tue, Oct 15, 2013 at 6:47 AM, Amr Elsadr 
>> <aelsadr@xxxxxxxxxxx<mailto:aelsadr@xxxxxxxxxxx>> wrote:
>> Hi Steve,
>>
>> I agree with most of your assessment except on what the question that needs 
>> answering. The way I see it is that we shouldn't be asking about exposure of 
>> a registrants registration data by Registrar in country A as opposed to 
>> exposure via Registry in country B. It's about the cross jurisdictional 
>> transfer of the data…, not the exposure. The exposure is the result of the 
>> transfer.
>>
>> The relevance of your question is significant for existing .com registrants 
>> (for example), but this PDP will also affect all future new gTLDs beyond the 
>> current round of new ones, and will probably affect new registrants who do 
>> not yet exist.
>>
>> Addressing the transfer of the registration data instead of the exposure 
>> covers both scenarios; the rights afforded to both existing and future 
>> registrants by legal/privacy protections.
>>
>> Thanks.
>>
>> Amr
>>
>> On Oct 14, 2013, at 11:25 PM, "Metalitz, Steven" 
>> <met@xxxxxxx<mailto:met@xxxxxxx>> wrote:
>>
>>> I have some concerns about this approach.   The registries (especially the 
>>> ones that would actually be undergoing the transition!) and the registrars 
>>> are big boys and girls.  They have been on notice for a long time that this 
>>> transition was under consideration, and indeed several of them have 
>>> participated actively in our working group.  Their consistent support for 
>>> the transition speaks volumes.  As our report states, “the fact that it 
>>> [the WG] can find no public objections from the registry or registrar 
>>> community indicates that no problems have been identified.”
>>>
>>> In any event, it is not ICANN’s job to look out for the legal interests of 
>>> registries and registrars.  Its focus should be on looking out for 
>>> registrants (it goes without saying that ICANN will look out for ICANN and 
>>> any potential corporate liabilities—which is in itself a reason why Alan’s 
>>> proposal may not be viable).  So if any legal review needs to be specified, 
>>> the main question ought to whether a registrant whose Whois data is 
>>> currently made publicly available  through a registrar in country A would 
>>> suffer any incremental legal harm or exposure  if the same data were also 
>>> made publicly available through a (thick) registry in the US, as is the 
>>> case now with all registrations in US-based thick registries that are 
>>> sponsored by non-US registrars.   The review should also consider whether 
>>> the  current contractual framework can be used to ameliorate any harms 
>>> found or whether it needs to be adjusted to accommodate this.  For example, 
>>> as an implementation matter, it could be useful for ICANN to provide 
>>> guidance on how the long-standing contractual requirement that registrars 
>>> give notice to, and obtain consent, from each registrant for uses of any 
>>> personally identifiable data submitted by the registrant should apply to 
>>> registrations involved in the transition.   See sections 3.7.7.4 through 
>>> 3.7.7.6 of the RAA (not changed from the 2009 to 2013 versions).
>>>
>>> Steve
>>>
>>>
>>> From: 
>>> owner-gnso-thickwhoispdp-wg@xxxxxxxxx<mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx>
>>>  [ 
>>> mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx<mailto:owner-gnso-thickwhoispdp-wg@xxxxxxxxx>]
>>>  On Behalf Of Alan Greenberg
>>> Sent: Monday, October 14, 2013 3:42 PM
>>> To: Volker Greimann; Rick Wesson
>>> Cc: Mike O'Connor; Thick Whois WG
>>> Subject: Re: [gnso-thickwhoispdp-wg] in preparation for the call tomorrow
>>>
>>> Let me try to describe what *I* think that we need from the "legal review". 
>>> I make no claim that it would satisfy NCSG not that it is viable (although 
>>> I think it is).
>>>
>>> We want a high degree of comfort that ICANN, the registry involved, and the 
>>> registrars involved will not be in violation of privacy legislation if a 
>>> transition from thick to thin WHOIS is carried out. A sample of registrar 
>>> should include those sponsoring large a plurality of the applicable 
>>> registrations as well as a sampling of the larger registrants in 
>>> jurisdictions with particularly stringent privacy laws (perhaps selected EU 
>>> countries, Canada, selected Asia-Pacific countries). For registries and 
>>> registrars, I would suggest that such a comfort level could be reached by 
>>> consulting with the selected registry and registrars, with the presumption 
>>> that they will consult their own legal counsels if needed.
>>>
>>> I use term "high degree of comfort" because I do not believe that we can 
>>> get an iron-clad guarantee - the privacy world is too complex. But I 
>>> believe that it is sufficient for going forward.
>>>
>>> Should the WG and ICANN staff agree, I would be pleased to try to put this 
>>> into more formal language.
>>>
>>> Alan
>>>
>>> At 14/10/2013 01:45 PM, Volker Greimann wrote:
>>>
>>> Rich,
>>>
>>> I think you are arguing a different issue here. The only issue we (and 
>>> therefore the legal review) need to be concerned with is the rights of the 
>>> parties listed in the whois in their own private details and how they may 
>>> be affected in a move of their data from whereever they are stored now to 
>>> the US, not third party rights. This is a greatly reduced scope from whe 
>>> indeed lunatic scenario you depict.
>>>
>>> Questions that need to be answered are:
>>> Do the general registration terms of most registrars cover such a move? I 
>>> would argue they do already for any registrar I have seen.
>>> What are the data protection requirements that the registry operator must 
>>> meet prior to being able to receive the data?
>>>
>>> Best,
>>>
>>> Volker
>>>
>>>
>>>
>>> Mike,
>>>
>>> Having spent some time in the IETF I find it hard to apply those rules you 
>>> outlined belwo, here. Our consensus is not about technical issues.
>>>
>>> Take for instance, the idea that a public record being published in 
>>> jurisdiction A is now published (publicly) in jurisdiction B and a third 
>>> party takes issue with the move, though this 3rd party has no relationship 
>>> to the domain, registrant, nor registrar A or B. Finally a 4th party takes 
>>> issue with the rights the 3rd party might have should the publishing of 
>>> this record change from A to B that they incest that ICANN review all 209 
>>> international laws on privacy and show how the 3rd party might be effected 
>>> should A or B land in any one of those places -- and provide a report to 
>>> the GNSO describing the 3rd parties effected rights.
>>>
>>> In the IETF we would have ignored such lunacy, because its not technical. 
>>> someone from the working group, probably the chair, would have sat these 
>>> folks down and asked them to focus one a more productive side of the 
>>> problems at hand. A good chair probably would have pushed for a binary 
>>> answer to the issue at hand. So that those consuming our work product would 
>>> have an answer -- preferably in binary.
>>>
>>> Since this is not the IETF, we might check our charter, which makes no 
>>> mention of rough consensus though many of the terms you defined are defined 
>>> at http 
>>> ://gnso.icann.org/en/issues/thick-whois-charter-08oct12-en.pdf<http://gnso.icann.org/en/issues/thick-whois-charter-08oct12-en.pdf>
>>>
>>>
>>> Finally, I'd like to point out that the IETF way you suggested is 
>>> orthoginal to the designations in our charter and I advise you remind the 
>>> working group of the charter and to follow those rules we have agreed to.
>>>
>>> -rick
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 14, 2013 at 9:39 AM, Mike O'Connor 
>>> <mike@xxxxxxxxxx<mailto:mike@xxxxxxxxxx>> wrote:
>>>
>>> hi all,
>>>
>>> i've been reflecting on where we're at and have arrived at two key words i 
>>> want us to focus on in preparation for the call tomorrow -- "objections" 
>>> and "precision"
>>>
>>> we've heard back from the General Counsel that they would like to see more 
>>> precision in our request for a legal review.  i wrote a response on the 
>>> spur of the moment that i'm regretting now.
>>>
>>> homework assignment:  try to come up with language that clarifies what we 
>>> are asking the GC to do, and also come up with language that limits the 
>>> scope of that effort to something that is achievable within reasonable time 
>>> and budget.
>>>
>>> i'm feeling the need to draw this part of the conversation to a close and 
>>> am hoping that we can get this last visit to the privacy issue completed on 
>>> the call tomorrow.  if, at the end of the call, we still are not there, i'm 
>>> going to ask the group's permission to go off and do the duty of the Chair, 
>>> which is to reflect on the state of our work with the following structure 
>>> in mind.
>>>
>>> IETF - Consensus
>>>
>>>   Credo
>>>      Do's
>>>        decisions are made by (more or less) consent of all participants
>>>
>>>        the actual products of engineering trump theoretical designs
>>>      Don'ts
>>>        we don't let a single individual make the decisions
>>>        nor do we let the majority dictate decisions
>>>
>>>        nor do we allow decisions to be made in a vacuum without practical 
>>> experience
>>>      Require rough, not full consensus
>>>        If the chair of a working group determines that a technical issue 
>>> brought forward by an objector has been truly considered by the working 
>>> group, and
>>>        the working group has made an informed decision that the objection 
>>> has been answered or is not enough of a technical problem to prevent moving 
>>> forward,
>>>
>>>          the chair can declare that there is rough consensus to go forward, 
>>> the objection notwithstanding.
>>>   Lack of disagreement is more important than agreement
>>>   _determining_ consensus and _coming to_ consensus are different things 
>>> than _having_ consensus
>>>      Consensus is not when everyone is happy and agrees that the chosen 
>>> solution is the best one
>>>      Consensus is when everyone is sufficiently satisfied with the chosen 
>>> solution, such that they no longer have specific objections to it
>>>
>>>      Engineering always involves a set of tradeoffs.  It is almost certain 
>>> that any time engineering choices need to be made, there will be options 
>>> that appeal to some people that are not appealing to some others.  The key 
>>> is to separate those choices that are simply unappealing from those that 
>>> are truly problematic.
>>>
>>> this outline is lifted from an IETF draft which seems like a good 
>>> guideline.  the full draft can be found here.
>>>
>>> http://tools.ietf.org/html/draft-resnick-on-consensus-05
>>>
>>> this is why i want us to focus on "objections" and "precision" on our call.
>>>
>>> mikey
>>>
>>> PHONE: 651-647-6109<tel:651-647-6109>, FAX: 866-280-2356<tel:866-280-2356>, 
>>> WEB: www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for 
>>> Twitter, Facebook, LinkedIn, etc.)
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> 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@xxxxxxxxxxxxxxx<mailto:vgreimann@xxxxxxxxxxxxxxx>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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@xxxxxxxxxxxxxxx<mailto:vgreimann@xxxxxxxxxxxxxxx>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>