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

[Carlton Samuels <carlton.samuels@xxxxxxxxx>]

Very helpful this!  I'm later to this circle than almost all of you and
this marks the first time I'm seeing a document that details this
proposition.

Many thanks Jeff.  Much obliged.

-Carlton


==============================
Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*
=============================


On Fri, Oct 18, 2013 at 8:06 AM, Neuman, Jeff <Jeff.Neuman@xxxxxxxxxx>wrote:

>  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)****
>
>  [image: 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> 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>
> >> Date: Tuesday, October 15, 2013 7:30 PM
> >> To: Amr Elsadr <aelsadr@xxxxxxxxxxx>
> >> Cc: Thick Thin PDP < 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>
> 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> 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] 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
> >>>
> >>>
> >>> 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>
> 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, FAX: 866-280-2356, WEB: 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 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@xxxxxxxxxxxxxxx
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>****
>
> ** **
>