Sources of Abuse Contact Info For Abuse Handlers
Colleagues, Mirjam Kuehne, L. Aaron Kaplan and Christian Teuschel have been doing a lot of work on a document on "Sources of Abuse Contact Info For Abuse Handlers". Versions of this document have been sent to the WG over the past year. There has been a lot of input from a lot of people and organisations and we'd like to thank them all. At this point it is our intend to publish this as a BCP RIPE Document from the AA-WG. At this point we would like to invite any final comments from the WG (a last call of sorts) before it is published. Ideally these comments would be great before the WG Session at 11:00 EET on Thursday 19th November, but definitely before the end of this week. Thanks again to all involved. Brian Co-Chair, RIPE Anti-Abuse WG -- Brian Nisbet, Network Operations Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +35316609040 web: http://www.heanet.ie/
Hello, This is a very interesting document, and a very nice thing to have (although it is unclear to me if the information in it is not too volatile for a BCP). This said, and I apologize for not having spotted this earlier, there are a few points that provoke some unease: - under point 4 it says implicitly that name-based whois is quicker outdated than number-based whois. Is there any hard data to back that statement up? - similarly: 6.6.8: The data gets continuously updated. With all the respect I have for the RIPE NCC (and that is a lot), unless some magic is involved this is a very optimistic statement. - finally 6.6.1, about the IRT object: I cannot argue about actual deployment, but the statement "The chances are high that this object will be dismissed and its functionality replaced by another object type." should not be in a BCP since it assumes the result of a future policy action (self-fulfilling prophecy?). And for the time being its functionality is largely superior to the abuse-c. I would not like to prevent publication by my comments, but please consider them as input to the discussion, if any. best, Gilles On 16/11/2015 17:33 , Brian Nisbet wrote:
Colleagues,
Mirjam Kuehne, L. Aaron Kaplan and Christian Teuschel have been doing a lot of work on a document on "Sources of Abuse Contact Info For Abuse Handlers". Versions of this document have been sent to the WG over the past year.
There has been a lot of input from a lot of people and organisations and we'd like to thank them all.
At this point it is our intend to publish this as a BCP RIPE Document from the AA-WG.
At this point we would like to invite any final comments from the WG (a last call of sorts) before it is published. Ideally these comments would be great before the WG Session at 11:00 EET on Thursday 19th November, but definitely before the end of this week.
Thanks again to all involved.
Brian Co-Chair, RIPE Anti-Abuse WG
A domain may expire in a year and then be recycled - registered by someone else, usually a domainer. On the other hand if someone takes the trouble to get a prefix, an ASN, transit / peering and such I dare say he won’t give up the prefix all that easily (barring accidents such as going out of business) The bar is much higher because 1. Far fewer prefixes than domains, by orders of magnitude 2. A single prefix can have thousands of domains hosted on it - sort of aggregating things very conveniently, abuse handling wise. —srs
On 17-Nov-2015, at 7:09 PM, Gilles Massen <gilles.massen@restena.lu> wrote:
- under point 4 it says implicitly that name-based whois is quicker outdated than number-based whois. Is there any hard data to back that statement up?
On 17 Nov 2015, at 15:45, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
A domain may expire in a year and then be recycled - registered by someone else, usually a domainer.
On the other hand if someone takes the trouble to get a prefix, an ASN, transit / peering and such I dare say he won’t give up the prefix all that easily (barring accidents such as going out of business)
The bar is much higher because
1. Far fewer prefixes than domains, by orders of magnitude
+1 higher costs than for a domain :) Very simple
2. A single prefix can have thousands of domains hosted on it - sort of aggregating things very conveniently, abuse handling wise.
—srs
On 17-Nov-2015, at 7:09 PM, Gilles Massen <gilles.massen@restena.lu> wrote:
- under point 4 it says implicitly that name-based whois is quicker outdated than number-based whois. Is there any hard data to back that statement up?
-- // CERT Austria // L. Aaron Kaplan <kaplan@cert.at> // T: +43 1 505 64 16 78 // http://www.cert.at // Eine Initiative der NIC.at Internet Verwaltungs- und Betriebs GmbH // http://www.nic.at/ - Firmenbuchnummer 172568b, LG Salzburg
Hi, We certainly agree on the facts :)
A domain may expire in a year and then be recycled - registered by someone else, usually a domainer.
On the other hand if someone takes the trouble to get a prefix, an ASN, transit / peering and such I dare say he won’t give up the prefix all that easily (barring accidents such as going out of business)
The bar is much higher because
1. Far fewer prefixes than domains, by orders of magnitude
+1 higher costs than for a domain :) Very simple
Yes, but I'd argue that if a domain really expires after one year, that means that the information is updated at the time of (re-)registration. The data for a prefix, while staying potentially longer the same, might more easily be forgotten. So the relative volatility of domains makes that data is corrected more often than for prefixes. But in absence of hard data is is speculation any way. Obviously, I'm assuming that you actually query the authoritative whois server and not try to keep copies.
2. A single prefix can have thousands of domains hosted on it - sort of aggregating things very conveniently, abuse handling wise.
Playing devil's advocate I'd argue that this means that domain name contacts are the more accurate information, because less aggregated. Convenience (and possibly efficiency) makes number-based investigations the better choice. And yet, this does not allow to conclude anything about the data accuracy in time. best, Gilles
—srs
On 17-Nov-2015, at 7:09 PM, Gilles Massen <gilles.massen@restena.lu> wrote:
- under point 4 it says implicitly that name-based whois is quicker outdated than number-based whois. Is there any hard data to back that statement up?
Dear WG, I have read the document and would like to thank the authors for their work. Some of my observations match and support points already raised by Gilles: On Tue, Nov 17, 2015 at 03:39:57PM +0200, Gilles Massen wrote:
This is a very interesting document, and a very nice thing to have (although it is unclear to me if the information in it is not too volatile for a BCP).
The end of chapter 4 reads:
This document is intended to be a request for input from the Internet community. As a next step we would like to define a standard API for abuse contact lookups.
This is consistent with the style and content of the paper but would not suggest a status of "Best Current Practice". Also, the document would benefit from some copy editing before publication. Some of the terms in section 2 do not appear in the rest of the paper or have been replaced - e.g., "registrant" is defined but "domain owner" is used (where "owner" is a suboptimal phrase for both domains and IP addresses). Also, while the example domain name is used, IP addresses should also come from the dedicated assignment. The intended audience section should be promoted to immediately follow the abstract, then followed by the problem statement. I'd like to see a clear distinction between "abuse" and "IT security incident", where both terms appear to be used interchangeably.
- under point 4 it says implicitly that name-based whois is quicker outdated than number-based whois. Is there any hard data to back that statement up?
I fail to see the relevance of this statement in the first place, especially given that the catalog in chapter 6 does not refer to any name based data repository - and rightfully so. The structure in chapter 6's catalog looks good, some prose elaborating the meaning of "first" or "second hand" sources could be helpful. What's the implication of either attribute? Same for the up-to-date-ness: the availability of per-object-timestamps might be more helpful than a general assessment of the repository, knowing that timestamps do not imply accuracy. Speaking of which: perpetuating the out of area examples in this document might turn out to be confusing. I'd like to understand the emphasis on "national CERTs". Regards, Peter
I also would like to thank the authours of this document. I think the document is well written and contains useful information. Speaking in IETF terms I would consider this document to be "informational" though, and not "bcp". A few remarks: Sources like TI or FIRST are useful if you are looking for national CERT contacts. If you want to report an issue to network operators or hosting providers directly, you have to use Whois information. Unfortunately, there are still lots of CIDRs for which the RIPE DB does not return a dedicated abuse contact. In some cases, you can find an appropriate contact in the "remarks" or other records - which is difficult to parse automatically. In other cases there is no contact information at all. Section 6.6.1 of this document says that "it [is] mandatory for every resource object (inetnum, inet6num and aut-num) to have a dedicated abuse contact." <nitpicking> ripe-563 states that "every direct allocated inetnum and inet6num needs to have an “abuse-c:”", which is different from "every" as is the quote above. </nitpicking> In fact, afaik you cannot add an abuse-c record to an inetnum object at all, can you? abuse-c records are usually added to higher level objects like LIR ORG and then inherited by the lower level inetnum objects. If you want to set a dedicated abuse-contact for an inetnum, you need to add a reference to an ORG object with the corresponding abuse-c record. (see https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-t...) Cheers, Markus -- Markus de Brün Federal Office for Information Security, Germany __________ ursprüngliche Nachricht __________ Von: Brian Nisbet <brian.nisbet@heanet.ie> Datum: Montag, 16. November 2015, 16:33:30 An: anti-abuse-wg@ripe.net Kopie: Betr.: [anti-abuse-wg] Sources of Abuse Contact Info For Abuse Handlers
Colleagues,
Mirjam Kuehne, L. Aaron Kaplan and Christian Teuschel have been doing a lot of work on a document on "Sources of Abuse Contact Info For Abuse Handlers". Versions of this document have been sent to the WG over the past year.
There has been a lot of input from a lot of people and organisations and we'd like to thank them all.
At this point it is our intend to publish this as a BCP RIPE Document from the AA-WG.
At this point we would like to invite any final comments from the WG (a last call of sorts) before it is published. Ideally these comments would be great before the WG Session at 11:00 EET on Thursday 19th November, but definitely before the end of this week.
Thanks again to all involved.
Brian Co-Chair, RIPE Anti-Abuse WG
On Wed, Nov 18, 2015 at 05:01:30PM +0100, de Brün, Markus wrote:
Unfortunately, there are still lots of CIDRs for which the RIPE DB does not return a dedicated abuse contact. In some cases, you can find an appropriate contact in the "remarks" or other records - which is difficult to parse automatically. In other cases there is no contact information at all.
And this is mostly the case of legacy resources. Hope we will deal with that.
Section 6.6.1 of this document says that "it [is] mandatory for every resource object (inetnum, inet6num and aut-num) to have a dedicated abuse contact."
<nitpicking> ripe-563 states that "every direct allocated inetnum and inet6num needs to have an ???abuse-c:???", which is different from "every" as is the quote above. </nitpicking>
I'm not sure what you are trying to say. RIPE-563 also states the same about aut-nums. And I'm pretty much sure that word "every" used in section 6.6.1 of the document mentioned above is used properly due to the hierarchical nature of IP address objects.
In fact, afaik you cannot add an abuse-c record to an inetnum object at all,
Not directly, but indirectly through organisation objects it is possible for any single inetnum object.
can you? abuse-c records are usually added to higher level objects like LIR ORG and then inherited by the lower level inetnum objects. If you want to set a dedicated abuse-contact for an inetnum, you need to add a reference to an ORG object with the corresponding abuse-c record. (see https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-t...)
This works the same way for allocations and assignments (and legacy as well). Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Hi All On 18/11/2015 19:31, Piotr Strzyzewski wrote:
On Wed, Nov 18, 2015 at 05:01:30PM +0100, de Brün, Markus wrote:
Unfortunately, there are still lots of CIDRs for which the RIPE DB does not return a dedicated abuse contact. In some cases, you can find an appropriate contact in the "remarks" or other records - which is difficult to parse automatically. In other cases there is no contact information at all.
And this is mostly the case of legacy resources. Hope we will deal with that.
Yes that is correct but there was also a problem with setting up the "abuse-c:" when new LIRs were registered which persisted long after the project for ensuring all resources issued by the RIPE NCC had an "abuse-c:". I believe this problem has since been resolved but there are still some resources that do not yet have an "abuse-c:" because of this. Some catching up and enforcing needs to be done.
Section 6.6.1 of this document says that "it [is] mandatory for every resource object (inetnum, inet6num and aut-num) to have a dedicated abuse contact."
<nitpicking> ripe-563 states that "every direct allocated inetnum and inet6num needs to have an ???abuse-c:???", which is different from "every" as is the quote above. </nitpicking>
I'm not sure what you are trying to say. RIPE-563 also states the same about aut-nums. And I'm pretty much sure that word "every" used in section 6.6.1 of the document mentioned above is used properly due to the hierarchical nature of IP address objects.
Again Piotr is correct. I think it is a question of how you interpret the word "have". Subject to above all resources must 'have' an "abuse-c:". When this was implemented it was decided not to make the reference directly from each resource object. There are over 3 million INETNUM objects which, through their hierarchical nature, reference tens of thousands of ORGANISATION objects. So rather than replicate the same information across so many objects it was decided to put the reference in the ORGANISATION object and inherit it in the resources. It was an example of how an organisation centric data model and the use of inheritance could dramatically reduce the amount of repetitive data in the database and make the whole system simpler and easier to manage. cheers denis
In fact, afaik you cannot add an abuse-c record to an inetnum object at all,
Not directly, but indirectly through organisation objects it is possible for any single inetnum object.
can you? abuse-c records are usually added to higher level objects like LIR ORG and then inherited by the lower level inetnum objects. If you want to set a dedicated abuse-contact for an inetnum, you need to add a reference to an ORG object with the corresponding abuse-c record. (see https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts-in-t...)
This works the same way for allocations and assignments (and legacy as well).
Piotr
Denis, Piotr, thanks for getting back to me. Comments inline __________ ursprüngliche Nachricht __________
Hi All
On 18/11/2015 19:31, Piotr Strzyzewski wrote:
On Wed, Nov 18, 2015 at 05:01:30PM +0100, de Brün, Markus wrote:
Unfortunately, there are still lots of CIDRs for which the RIPE DB does not return a dedicated abuse contact. In some cases, you can find an appropriate contact in the "remarks" or other records - which is difficult to parse automatically. In other cases there is no contact information at all.
And this is mostly the case of legacy resources. Hope we will deal with that.
Yes that is correct but there was also a problem with setting up the "abuse-c:" when new LIRs were registered which persisted long after the project for ensuring all resources issued by the RIPE NCC had an "abuse-c:". I believe this problem has since been resolved but there are still some resources that do not yet have an "abuse-c:" because of this. Some catching up and enforcing needs to be done.
Thanks for explaining. I would still suggest a clarification to the text, because you could get the impression that there is always an abuse-c. And we are not there yet.
Section 6.6.1 of this document says that "it [is] mandatory for every resource object (inetnum, inet6num and aut-num) to have a dedicated abuse contact."
<nitpicking> ripe-563 states that "every direct allocated inetnum and inet6num needs to have an ???abuse-c:???", which is different from "every" as is the quote above. </nitpicking>
I'm not sure what you are trying to say. RIPE-563 also states the same about aut-nums. And I'm pretty much sure that word "every" used in section 6.6.1 of the document mentioned above is used properly due to the hierarchical nature of IP address objects.
Again Piotr is correct. I think it is a question of how you interpret the word "have". Subject to above all resources must 'have' an "abuse-c:". When this was implemented it was decided not to make the reference directly from each resource object. There are over 3 million INETNUM objects which, through their hierarchical nature, reference tens of thousands of ORGANISATION objects. So rather than replicate the same information across so many objects it was decided to put the reference in the ORGANISATION object and inherit it in the resources. It was an example of how an organisation centric data model and the use of inheritance could dramatically reduce the amount of repetitive data in the database and make the whole system simpler and easier to manage. Makes sense. This is essentially what I was trying to describe. I would suggest to make this more explicit in the document. That is to say "an INETNUM references an ORG which in turn contains an abuse-c" instead of "an INETNUM has an abuse-c".
Cheers, Markus
cheers denis
In fact, afaik you cannot add an abuse-c record to an inetnum object at all,
Not directly, but indirectly through organisation objects it is possible for any single inetnum object.
can you? abuse-c records are usually added to higher level objects like LIR ORG and then inherited by the lower level inetnum objects. If you want to set a dedicated abuse-contact for an inetnum, you need to add a reference to an ORG object with the corresponding abuse-c record. (see https://labs.ripe.net/Members/denis/creating-and-finding-abuse-contacts- in-the-ripe-database)
This works the same way for allocations and assignments (and legacy as well).
Piotr
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <201511181701.30630.markus.debruen@bsi.bund.de>, de =?utf- 8?q?Br=C3=BCn?=, Markus <markus.debruen@bsi.bund.de> writes
A few remarks: Sources like TI or FIRST are useful if you are looking for national CERT contacts. If you want to report an issue to network operators or hosting providers directly, you have to use Whois information.
nope ... you could use their websites Many hosting providers have webforms, which if used result in rapid takedown. Indeed for many hosting companies this is pretty much the only way of achieving rapid takedown. I understand that the purpose of the document is to explain the issues around "let's get hold of the abuse@ folk" but it would be considerably more valuable if it either indicated that this was just one strategy for dealing with abuse or at least pointed at other material that set out the context. The document provides the example such as "Incident reporter finds a hacked webpage" and says "Naturally, she will try to contact the domain owner (name-based resource lookup) - the admin-c and possibly also the tech-c." in practice people do indeed contact all three of these, and that can cause significant delay as each assumes someone else has dealt with it; and as above it may well be better to just type www.hostingcompany.tld and click on the "report abuse" link. My suggestion for the document would be to entirely remove what material there is on why one might be searching for an abuse contact (since it is inadequate and unhelpful) and leave just the substantive information (these are the databases, this is what they contain, this is how they are maintained). Bottom line for me is that the problem statement says Given the domain www.example.com, what is the best contact for sending IT security incident notifications to? and nothing in the rest of the document tackles the notion of "best" So I'd commend removing sections 4 and 5 altogether. - -- Dr Richard Clayton <richard.clayton@cl.cam.ac.uk> Director, Cambridge Cloud Cybercrime Centre mobile: +44 (0)7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD tel: +44 (0)1223 763570 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBVk29jOINNVchEYfiEQLL9ACfQIhpmr8Doa2YUVAvf+kIT2pK8IAAoPFM OEwLI5XKS2mU+CDpjABG0FWY =fpnQ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <5649F74A.70304@heanet.ie>, Brian Nisbet <brian.nisbet@heanet.ie> writes
At this point we would like to invite any final comments from the WG (a last call of sorts) before it is published. Ideally these comments would be great before the WG Session at 11:00 EET on Thursday 19th November, but definitely before the end of this week.
I am concerned about the section on Geolocation -- not least because Geolocation doesn't work all that well, especially when abuse is occurring and the bad guys are seeking to confuse. The section starts: As discussed in the section "General remarks on abuse contact lookups", some incident reports should simply go to the national CERT. For this task, it is important to find the country code of an IP address or a domain. There is no further discussion of domains ... many of which don't have a "country code" and indeed many country codes are not operated by the relevant country (albeit if such a country had a CERT I expect they'd be happy to take the report and would have good contacts with the relevant people who could actually take action). So why mention domains at all ? Mapping IP addresses to a country and an AS works well most of the time, but the lack of any security in BGP means that the data one obtains from the RIRs or indeed from the "global routing table" [why is Team Cymru mentioned and not stat.ripe.net ??] requires careful interpretation. The suggestion of running your own copy of Quagga is a wise one, not least because an important way of dealing with abuse when an abuse contact cannot be found or does not respond is to deal with the company that is providing connectivity to the dubious block of IPs -- the routing table gives an indication (often, but not invariably, a correct indication) who that might be.... ... but now we're straying into advice as to how to deal with abuse rather than information about datasets... the change required to the document is a "known issues" statement about Geolocation (perhaps shorter than this): Maxmind -- deductions are made from other datasets and assumptions are made that delegating a block of address space to a company in country X means that the address space is in use in country X Team Cymru -- this is also derived data. For country it is assumes entire blocks are in a single country. For ASs it reports the BGP data that Team Cymru is aware of. Quagga -- data can require careful interpretation because of the lack of security in BGP generally - -- Dr Richard Clayton <richard.clayton@cl.cam.ac.uk> Director, Cambridge Cloud Cybercrime Centre mobile: +44 (0)7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD tel: +44 (0)1223 763570 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBVk3Bs+INNVchEYfiEQKc3ACfT7LuERV/DOfsjszwGzTqK51xgxoAoKLh avq/5iqVytoYHxzei2/8b9tg =qysj -----END PGP SIGNATURE-----
Hi, Thank you all for your feedback on the list and also in person during the RIPE Meeting. We will see how we can best incorporate your comments and will send a new version of the document to the list shortly. Kind regards, Mirjam On 16/11/15 16:33, Brian Nisbet wrote:
Colleagues,
Mirjam Kuehne, L. Aaron Kaplan and Christian Teuschel have been doing a lot of work on a document on "Sources of Abuse Contact Info For Abuse Handlers". Versions of this document have been sent to the WG over the past year.
There has been a lot of input from a lot of people and organisations and we'd like to thank them all.
At this point it is our intend to publish this as a BCP RIPE Document from the AA-WG.
At this point we would like to invite any final comments from the WG (a last call of sorts) before it is published. Ideally these comments would be great before the WG Session at 11:00 EET on Thursday 19th November, but definitely before the end of this week.
Thanks again to all involved.
Brian Co-Chair, RIPE Anti-Abuse WG
On 11/25/2015 12:17 PM, Mirjam Kuehne wrote:
Hi,
Thank you all for your feedback on the list and also in person during the RIPE Meeting. We will see how we can best incorporate your comments and will send a new version of the document to the list shortly.
Kind regards, Mirjam
Thanks for the document, seems to be helpful! One point: I miss the public available ABUSIX database, which is very complete and accurate. (still some addresses missing, especially for AFRINIC, but hey..) https://abusix.com/contactdb.html Since they do actively sending out millions of complaints every day, they should know where to send them to. This is at least my preferred source for finding an abuse contact. I wonder why this DB is not included in the document, especially since Tobias Knecht, former co-head of this working group, is the founder of Abusix.. The part for geolocation is indeed not necessary or helpful imho. best greetings, Gunther NetCologne Systemadministration -- NetCologne Gesellschaft für Telekommunikation mbH Am Coloneum 9 ; 50829 Köln Geschäftsführer: Jost Hermanns, Mario Wilhelm Vorsitzender des Aufsichtsrates: Dr. Andreas Cerbe HRB 25580, AG Köln
Dear Gunther, Thanks for your suggestion. Prior to sending this document around, we discussed this with Tobias Knecht and agreed not to include abusix at this stage since it it mainly an interface to existing data sets and not a separate data set on its own. As a next step we would like to work with the other RIRs to see if they're implementing similar concepts (such as abuse-c) and how we can possibly include that in the next version of the document. At that stage, it might make sense to also link to the abusix interface. And we'll review the geolocation section, based on the comments sent to the list. If you have any other suggestions or comments, please let us know. Kind regards, Mirjam On 25/11/15 14:31, Gunther Nitzsche wrote:
On 11/25/2015 12:17 PM, Mirjam Kuehne wrote:
Hi,
Thank you all for your feedback on the list and also in person during the RIPE Meeting. We will see how we can best incorporate your comments and will send a new version of the document to the list shortly.
Kind regards, Mirjam
Thanks for the document, seems to be helpful!
One point: I miss the public available ABUSIX database, which is very complete and accurate. (still some addresses missing, especially for AFRINIC, but hey..)
https://abusix.com/contactdb.html
Since they do actively sending out millions of complaints every day, they should know where to send them to.
This is at least my preferred source for finding an abuse contact.
I wonder why this DB is not included in the document, especially since Tobias Knecht, former co-head of this working group, is the founder of Abusix..
The part for geolocation is indeed not necessary or helpful imho.
best greetings,
Gunther
NetCologne Systemadministration
Gunther, On 25/11/2015 13:31, Gunther Nitzsche wrote:
I wonder why this DB is not included in the document, especially since Tobias Knecht, former co-head of this working group, is the founder of Abusix..
A quick point, Tobias is still co-chair of the working group. He was re-affirmed at the meeting in Bucharest. I should have made that more clear and will send a distinct announcement to the list now. Brian
participants (11)
-
Brian Nisbet -
de Brün, Markus -
denis -
Gilles Massen -
Gunther Nitzsche -
L. Aaron Kaplan -
Mirjam Kuehne -
Peter Koch -
Piotr Strzyzewski -
Richard Clayton -
Suresh Ramasubramanian