One Way Gated Access to Data Might Work
I like to explore how systems might work by putting thoughts into action with running code. I have a working implementation of RDAP with client authentication that might be useful in helping people see how some of our data element and data access ideas might actually work in practice. The implementation currently includes three levels of client/end user access: 1. Unauthenticated: a client that does not provide any authentication information to the server will receive responses that include very little information beyond what is currently available from the DNS. 2. Authenticated Basic: a client that authenticates using an easily acquired, open credential (like a Gmail or Hotmail email account) will receive additional information (like registration dates and domain status values), but no personally identifiable contact information. 3. Authenticated Advanced: a client who authenticates using a specialized identity provider (we currently support providers implemented by Verisign Labs, CZNIC and an interoperability test provider) will receive full access to all available data. The purpose of the query can be identified and shared with the server operator, who can use the client-supplied identity information to make fine-grained access control decisions. A web-based front-end to the service can be found here: https://rdap.verisignlabs.com/ We currently support entity (contact), name server, and domain lookup and search queries for the .cc and .tv ccTLDs. You can use the nic.tv domain for basic exploration. Try it out with your Gmail address using the "Authenticate" button to see the difference between authenticated and unauthenticated behaviors. A word of warning: RDAP responses are JSON-encoded and *very* character-dense. It may help to have a JSON pretty printer plugin installed in your browser. Anyone who wants a test account from Verisign Labs for advanced authenticated access can have one for the asking. Please reply directly to me and I'll make sure you get set up. A logical conclusion should we decide to pursue this line of thinking is that there will be a need for identity providers who are able to issue user credentials to people who belong to specific communities of interest. Policies will need to be developed to determine which communities of interest get access to which data elements. Scott
Hello Scott, Great, I like the three levels model and it copes/align well with our need regarding this requirement. Best Regards @__f_f__ about.me/farell ________________________________. Mail sent from my mobile phone. Excuse for brievety. Le 9 déc. 2016 12:25, "Hollenbeck, Scott" <shollenbeck@verisign.com> a écrit :
I like to explore how systems might work by putting thoughts into action with running code. I have a working implementation of RDAP with client authentication that might be useful in helping people see how some of our data element and data access ideas might actually work in practice. The implementation currently includes three levels of client/end user access:
1. Unauthenticated: a client that does not provide any authentication information to the server will receive responses that include very little information beyond what is currently available from the DNS.
2. Authenticated Basic: a client that authenticates using an easily acquired, open credential (like a Gmail or Hotmail email account) will receive additional information (like registration dates and domain status values), but no personally identifiable contact information.
3. Authenticated Advanced: a client who authenticates using a specialized identity provider (we currently support providers implemented by Verisign Labs, CZNIC and an interoperability test provider) will receive full access to all available data. The purpose of the query can be identified and shared with the server operator, who can use the client-supplied identity information to make fine-grained access control decisions.
A web-based front-end to the service can be found here:
https://rdap.verisignlabs.com/
We currently support entity (contact), name server, and domain lookup and search queries for the .cc and .tv ccTLDs. You can use the nic.tv domain for basic exploration. Try it out with your Gmail address using the "Authenticate" button to see the difference between authenticated and unauthenticated behaviors.
A word of warning: RDAP responses are JSON-encoded and *very* character-dense. It may help to have a JSON pretty printer plugin installed in your browser.
Anyone who wants a test account from Verisign Labs for advanced authenticated access can have one for the asking. Please reply directly to me and I'll make sure you get set up.
A logical conclusion should we decide to pursue this line of thinking is that there will be a need for identity providers who are able to issue user credentials to people who belong to specific communities of interest. Policies will need to be developed to determine which communities of interest get access to which data elements.
Scott _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Scott, On Fri, Dec 09, 2016 at 12:25:04PM +0000, Hollenbeck, Scott wrote:
I have a working implementation of RDAP with client authentication that might be useful in helping people see how some of our data element and data access ideas might actually work in practice.
This is fantastic news; thanks for doing it. I strongly encourage anyone who has opinions about whether a given field is necessary under various circumstances to try this system out, because I think it shows really nicely how the differential capabilities can be useful. I will note, also, that this is entirely in line with some encouragement the IAB submitted to the discussion about the "consistent display" public comment: https://forum.icann.org/lists/comments-rdds-output-20oct16/msg00000.html (Full disclosure: I'm currently the IAB chair.)
A logical conclusion should we decide to pursue this line of thinking is that there will be a need for identity providers who are able to issue user credentials to people who belong to specific communities of interest. Policies will need to be developed to determine which communities of interest get access to which data elements.
The nice thing, however, is that the demonstration shows how easily new policies of that sort could work. It's probably true that thousands of policies would be onerous, but I find it hard to imagine the scenario where we come up even with hundreds, so the approach ought to scale appropriately. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew & all, [ Sorry I have been disconnected from this WG for a while, but am trying to catch up and re-engage. Apologies if I am revisiting old ground. ] At 2016-12-09 10:03:28 -0500 Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
A logical conclusion should we decide to pursue this line of thinking is that there will be a need for identity providers who are able to issue user credentials to people who belong to specific communities of interest. Policies will need to be developed to determine which communities of interest get access to which data elements.
The nice thing, however, is that the demonstration shows how easily new policies of that sort could work. It's probably true that thousands of policies would be onerous, but I find it hard to imagine the scenario where we come up even with hundreds, so the approach ought to scale appropriately.
This is pretty much the kind of capability that I envisioned the whole time that we have been discussing RDS. It's nice to have a running example to help us all understand the possibilities. :) ---- I still think we're missing a big piece of the picture, which is how data about queries is handled by the operator of the RDAP service. Even though the "terms & conditions" scroll off my high-resolution monitor with a wall of legalese, the Verisign Labs terms & conditions do not seem to say anything about what happens to information about the queries I make. Presumably Verisign is logging these, but I don't know what they are logging or how long they keep this information. I don't know who has access to these logs. I really think there should be a very few standard models for this, so that they can be explored in depth. This is in direct contradiction to the idea of every registry and/or registrar making their own walls of subtly-different legalese - which we should avoid at all cost. Such a set of standard "usage agreements" would also mean that a server can present these as data about the service. ---- Further, do people who have their domain information queried know about this? Personally I think this is a desirable goal; it would be nice to know how many spammers and/or LEA have been granted access to my data. ;) Again, a small set of standard practices for this seems highly desirable. Cheers, -- Shane
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org] On Behalf Of Shane Kerr Sent: Wednesday, December 14, 2016 9:31 AM To: Andrew Sullivan Cc: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] One Way Gated Access to Data Might Work
Andrew & all,
[ Sorry I have been disconnected from this WG for a while, but am trying to catch up and re-engage. Apologies if I am revisiting old ground. ]
At 2016-12-09 10:03:28 -0500 Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
A logical conclusion should we decide to pursue this line of thinking is that there will be a need for identity providers who are able to issue user credentials to people who belong to specific communities of interest. Policies will need to be developed to determine which communities of interest get access to which data elements.
The nice thing, however, is that the demonstration shows how easily new policies of that sort could work. It's probably true that thousands of policies would be onerous, but I find it hard to imagine the scenario where we come up even with hundreds, so the approach ought to scale appropriately.
This is pretty much the kind of capability that I envisioned the whole time that we have been discussing RDS. It's nice to have a running example to help us all understand the possibilities. :)
----
I still think we're missing a big piece of the picture, which is how data about queries is handled by the operator of the RDAP service. Even though the "terms & conditions" scroll off my high-resolution monitor with a wall of legalese, the Verisign Labs terms & conditions do not seem to say anything about what happens to information about the queries I make.
Presumably Verisign is logging these, but I don't know what they are logging or how long they keep this information. I don't know who has access to these logs.
FWIW we're not logging queries. Scott
Scott, At 2016-12-14 14:41:20 +0000 "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
Presumably Verisign is logging these, but I don't know what they are logging or how long they keep this information. I don't know who has access to these logs.
FWIW we're not logging queries.
haha... thanks for the information. Note that I wasn't trying to pick on Verisign Labs or Verisign in general! I think it's great that you have set up this demo. Cheers, -- Shane
Thanks for jumping back into the fray Shane. The issues you raise are all ones that we will need to confront later in Phase 1 when we talk further about privacy and risks and also when we get into policy and implementation discussions in Phases 2 & 3. Chuck -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Shane Kerr Sent: Wednesday, December 14, 2016 9:31 AM To: Andrew Sullivan <ajs@anvilwalrusden.com> Cc: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] One Way Gated Access to Data Might Work Andrew & all, [ Sorry I have been disconnected from this WG for a while, but am trying to catch up and re-engage. Apologies if I am revisiting old ground. ] At 2016-12-09 10:03:28 -0500 Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
A logical conclusion should we decide to pursue this line of thinking is that there will be a need for identity providers who are able to issue user credentials to people who belong to specific communities of interest. Policies will need to be developed to determine which communities of interest get access to which data elements.
The nice thing, however, is that the demonstration shows how easily new policies of that sort could work. It's probably true that thousands of policies would be onerous, but I find it hard to imagine the scenario where we come up even with hundreds, so the approach ought to scale appropriately.
This is pretty much the kind of capability that I envisioned the whole time that we have been discussing RDS. It's nice to have a running example to help us all understand the possibilities. :) ---- I still think we're missing a big piece of the picture, which is how data about queries is handled by the operator of the RDAP service. Even though the "terms & conditions" scroll off my high-resolution monitor with a wall of legalese, the Verisign Labs terms & conditions do not seem to say anything about what happens to information about the queries I make. Presumably Verisign is logging these, but I don't know what they are logging or how long they keep this information. I don't know who has access to these logs. I really think there should be a very few standard models for this, so that they can be explored in depth. This is in direct contradiction to the idea of every registry and/or registrar making their own walls of subtly-different legalese - which we should avoid at all cost. Such a set of standard "usage agreements" would also mean that a server can present these as data about the service. ---- Further, do people who have their domain information queried know about this? Personally I think this is a desirable goal; it would be nice to know how many spammers and/or LEA have been granted access to my data. ;) Again, a small set of standard practices for this seems highly desirable. Cheers, -- Shane
Way to go Scott! -Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Fri, Dec 9, 2016 at 7:25 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
I like to explore how systems might work by putting thoughts into action with running code. I have a working implementation of RDAP with client authentication that might be useful in helping people see how some of our data element and data access ideas might actually work in practice. The implementation currently includes three levels of client/end user access:
1. Unauthenticated: a client that does not provide any authentication information to the server will receive responses that include very little information beyond what is currently available from the DNS.
2. Authenticated Basic: a client that authenticates using an easily acquired, open credential (like a Gmail or Hotmail email account) will receive additional information (like registration dates and domain status values), but no personally identifiable contact information.
3. Authenticated Advanced: a client who authenticates using a specialized identity provider (we currently support providers implemented by Verisign Labs, CZNIC and an interoperability test provider) will receive full access to all available data. The purpose of the query can be identified and shared with the server operator, who can use the client-supplied identity information to make fine-grained access control decisions.
A web-based front-end to the service can be found here:
https://rdap.verisignlabs.com/
We currently support entity (contact), name server, and domain lookup and search queries for the .cc and .tv ccTLDs. You can use the nic.tv domain for basic exploration. Try it out with your Gmail address using the "Authenticate" button to see the difference between authenticated and unauthenticated behaviors.
A word of warning: RDAP responses are JSON-encoded and *very* character-dense. It may help to have a JSON pretty printer plugin installed in your browser.
Anyone who wants a test account from Verisign Labs for advanced authenticated access can have one for the asking. Please reply directly to me and I'll make sure you get set up.
A logical conclusion should we decide to pursue this line of thinking is that there will be a need for identity providers who are able to issue user credentials to people who belong to specific communities of interest. Policies will need to be developed to determine which communities of interest get access to which data elements.
Scott _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Interesting, but I am not sure this is ultimately what we should be looking for for one simple reason. This proposed implementation apparently does not provide for any differentiation between access levels except for the three authentification levels. So once one obtains and advanced authentification, one can access all data in the database, which I would consider insufficient differentiation. Access should be further scecialized on a "need to know" and "right to know" basis. For example, should a certified and authentificated law enforcement agency have access to all registrant data or only to registrant data that applies to their jurisdiction (plus maybe an identifier that details which jurisdiction applies to a data set that agency cannot access). Similarly, would a IP rights holder have access to all data or only to just enough data needed to achieve their goal, which would likely be to contact the registrant? In other words, the access level scheme should differentiate between levels of access much more and restrict that access to those with a right to access or a legitimate need to access without overstepping legal or jurisdictional boundaries. This proposed implementation it too simplistic. Best, volker Am 10.12.2016 um 06:35 schrieb Carlton Samuels:
Way to go Scott!
-Carlton
============================== /Carlton A Samuels/ /Mobile: 876-818-1799 Strategy, Planning, Governance, Assessment & Turnaround/ =============================
On Fri, Dec 9, 2016 at 7:25 AM, Hollenbeck, Scott <shollenbeck@verisign.com <mailto:shollenbeck@verisign.com>> wrote:
I like to explore how systems might work by putting thoughts into action with running code. I have a working implementation of RDAP with client authentication that might be useful in helping people see how some of our data element and data access ideas might actually work in practice. The implementation currently includes three levels of client/end user access:
1. Unauthenticated: a client that does not provide any authentication information to the server will receive responses that include very little information beyond what is currently available from the DNS.
2. Authenticated Basic: a client that authenticates using an easily acquired, open credential (like a Gmail or Hotmail email account) will receive additional information (like registration dates and domain status values), but no personally identifiable contact information.
3. Authenticated Advanced: a client who authenticates using a specialized identity provider (we currently support providers implemented by Verisign Labs, CZNIC and an interoperability test provider) will receive full access to all available data. The purpose of the query can be identified and shared with the server operator, who can use the client-supplied identity information to make fine-grained access control decisions.
A web-based front-end to the service can be found here:
https://rdap.verisignlabs.com/
We currently support entity (contact), name server, and domain lookup and search queries for the .cc and .tv ccTLDs. You can use the nic.tv <http://nic.tv> domain for basic exploration. Try it out with your Gmail address using the "Authenticate" button to see the difference between authenticated and unauthenticated behaviors.
A word of warning: RDAP responses are JSON-encoded and *very* character-dense. It may help to have a JSON pretty printer plugin installed in your browser.
Anyone who wants a test account from Verisign Labs for advanced authenticated access can have one for the asking. Please reply directly to me and I'll make sure you get set up.
A logical conclusion should we decide to pursue this line of thinking is that there will be a need for identity providers who are able to issue user credentials to people who belong to specific communities of interest. Policies will need to be developed to determine which communities of interest get access to which data elements.
Scott _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Volker Greimann Sent: Monday, December 12, 2016 9:13 AM To: gnso-rds-pdp-wg@icann.org Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] One Way Gated Access to Data Might Work Interesting, but I am not sure this is ultimately what we should be looking for for one simple reason. This proposed implementation apparently does not provide for any differentiation between access levels except for the three authentification levels. [SAH] No, not true. While this particular experiment includes three levels of access, the approach is designed to be tailored to make authorization and access control decisions based on a number of different factors. What you currently see in my experiment is just one possibility. It already includes support for specification of query purpose (for example), and that information can be used to provide additional levels of access control based on the policies implemented by the server operator. So once one obtains and advanced authentification, one can access all data in the database, which I would consider insufficient differentiation. Access should be further scecialized on a "need to know" and "right to know" basis. For example, should a certified and authentificated law enforcement agency have access to all registrant data or only to registrant data that applies to their jurisdiction (plus maybe an identifier that details which jurisdiction applies to a data set that agency cannot access). [SAH] The actual protocol proposal* I've developed includes support for specification of a query purpose that can be used to make more specific access control decisions. If other factors are needed, they, too, can be included. Similarly, would a IP rights holder have access to all data or only to just enough data needed to achieve their goal, which would likely be to contact the registrant? In other words, the access level scheme should differentiate between levels of access much more and restrict that access to those with a right to access or a legitimate need to access without overstepping legal or jurisdictional boundaries. This proposed implementation it too simplistic. [SAH] In no way did I infer that the existing implementation is "final" or a complete solution. It is just an early proposal and an early experiment to demonstrate possibilities. I fully expect to make revisions based on the outputs of this WG. Scott * https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/
Hi Scott, thank you for your clarification. That reaction was based on my misconception of the proposal then. I am looking forward to seeing how this evolves further. Best, Volker Am 12.12.2016 um 15:45 schrieb Hollenbeck, Scott:
*From:*gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Volker Greimann *Sent:* Monday, December 12, 2016 9:13 AM *To:* gnso-rds-pdp-wg@icann.org *Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg] One Way Gated Access to Data Might Work
Interesting, but I am not sure this is ultimately what we should be looking for for one simple reason. This proposed implementation apparently does not provide for any differentiation between access levels except for the three authentification levels.
[SAH] No, not true. While this particular experiment includes three levels of access, the approach is designed to be tailored to make authorization and access control decisions based on a number of different factors. What you currently see in my experiment is just one possibility. It already includes support for specification of query purpose (for example), and that information can be used to provide additional levels of access control based on the policies implemented by the server operator.
So once one obtains and advanced authentification, one can access all data in the database, which I would consider insufficient differentiation. Access should be further scecialized on a "need to know" and "right to know" basis. For example, should a certified and authentificated law enforcement agency have access to all registrant data or only to registrant data that applies to their jurisdiction (plus maybe an identifier that details which jurisdiction applies to a data set that agency cannot access).
[SAH] The actual protocol proposal* I’ve developed includes support for specification of a query purpose that can be used to make more specific access control decisions. If other factors are needed, they, too, can be included.
Similarly, would a IP rights holder have access to all data or only to just enough data needed to achieve their goal, which would likely be to contact the registrant?
In other words, the access level scheme should differentiate between levels of access much more and restrict that access to those with a right to access or a legitimate need to access without overstepping legal or jurisdictional boundaries.
This proposed implementation it too simplistic.
[SAH] In no way did I infer that the existing implementation is “final” or a complete solution. It is just an early proposal and an early experiment to demonstrate possibilities. I fully expect to make revisions based on the outputs of this WG.
Scott
* https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/
-- 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@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
participants (7)
-
Andrew Sullivan -
Carlton Samuels -
Farell Folly -
Gomes, Chuck -
Hollenbeck, Scott -
Shane Kerr -
Volker Greimann