1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

319

______________________________________________________

NATIONAL INDIAN GAMING COMMISSION

TRIBAL ADVISORY COMMITTEE MEETING

NOVEMBER 16, 2011

VOLUME II

______________________________________________________

DATE: November 15 - 17, 2011

PLACE: Hilton Garden Inn

815 East Mall Drive

Rapid City, South Dakota 57701
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

320

I N D E X

TAC MEMBERS PRESENT:

John Magee, Gaming Commissioner, Pechanga Band

of Luiseño Mission Indians

Kathi Hamel, Casino General Manager, Lytton

Rancheria of California

Jason Ramos, Gaming Commission Chairman, Blue

Lake Rancheria

Daniel K. McGhee, Gaming Commission

Administrator, Poarch Band of Creek Indians

Brian Callaghan, Gaming Commission Executive

Director, Pokagon Band of Potawatomi Indians

Christinia Thomas, Office of Gaming Regulation

and Compliance Executive Director, Mille Lacs

Band of Ojibwe

Steve Garvin, Gaming Commissioner, Ho-Chunk

Nation

Jeff Wheatley, Director of Gaming,

Stillaguamish Tribe of Indians

Michele Stacona, Gaming Commission Executive

Director, The Confederated Tribes of the Warm

Springs Reservation of Oregon

Leo Culloo, General Manager of The Point

Casino, Port Gamble S’Klallam Tribe

Mia M. Tahdooahnippah, Gaming Commission

Compliance Director, Comanche Nation

Robin Lash, Gaming Commissioner, Miami Tribe

of Oklahoma

Matthew Morgan, Gaming Commissioner, Chickasaw

Nation

Thomas Wilson, Gaming Commission Executive

Director, Pascua Yaqui Tribe

Carleen Chino, Gaming Commissioner Executive

Director, The Navajo Nation

NIGC SPEAKERS:

David Little

Nimish Purohit

R. Rust West

Tracie Stevens

Michael Hoenig

FACILITATOR:

Robert Fisher
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

321

(November 16, 2011, at 8:11 a.m.)

MR. FISHER: Good morning, everybody.

Welcome. So in a moment, let's go over the

agenda for the day and figure out where we're

going to start up this morning. Before I do

that, let me just request that for those people

who are in the audience, we ask that you sign in.

There's a sign-in sheet on the other side of the

door, and there's also a separate sign-in sheet

for you if you want to give public comment to the

tribal advisory committee either this morning or

this afternoon. All right.

So generally, we can start -- we're going

to pick up this morning on the technical

standards.

MR. WILSON: Robert, I'd like to request

that if the TAC can go into executive session for

a few minutes, there's some issues we'd like to

discuss. And then we can proceed on with the

agenda.

MR. FISHER: Okay. So you want to go into

executive session and you just want the TAC

members present. Okay.

(Executive session - Discussion held off

the record.)
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

322

MR. WILSON: So the fellow TAC-ians, we

have concluded that we'd like to go on the

record; that at the beginning of each meeting,

we'll have an executive session. It helps us in

organizing our day. So that will just become

part of the process going forward. And so that

can actually be an agenda item, I guess, that we

have an executive session first. And then we

will have an executive session, request executive

session today prior to discussion of the MICS.

There's some philosophical things that we believe

are important for the group to get their head

around first so that we can have a more effective

discussion when we get to that.

And then the other thing is we just want

to make sure that what's on the screen, that the

documents on the screen are -- the only documents

that we're looking at are the ones from the NIGC

website and the submittal documents from Poarch

Creek, so that we don't have any confusion about

which version or what it is that we're working

off of from that standpoint.

And then finally, we discussed the

realization that the document that NIGC sent out,

the summary document that is only pieces of the
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

323

entire document, and that there could be other

changes in the entire document that we're not

discussing because we're focusing on that. And a

question that the TAC has for the NIGC on that

is, is the presumption that we should take that,

the only areas that you have concerns about are

those that are in the summary document and that

we can go on the premise that the rest of the

document that may have other changes in it are

not an issue with the NIGC?

MR. LITTLE: Is that question for me? No,

actually there's other areas that we do want to

discuss, including, you know, wide area networks,

downloadable software, things like that. So

there are some areas that we do want to kind of

talk about. And then also I think it was very

helpful when it was kind of opened up yesterday

where TAC members had really gone through the

document, had raised, you know, specific issues

there. So we're definitely interested in making

sure that there's a thorough scrub of that whole

regulation and that any areas that folks feel

need to be addressed are addressed.

MR. WILSON: So I just -- and, Robert, for

your benefit as a facilitator, you know, we were
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

324

sort of going on that only that summary document

was the primary focus of what we were to discuss.

But in that case, you know, Dan, based on what

you're saying, we don't want to lose sight of the

bigger document; that everybody is comfortable

that they can bring forward anything that's in

that document, that we're not just limited to the

summary document.

MR. LITTLE: I think when Nimish and our

former associate general councilman went through

it, they just picked the large concepts and made

their changes, and that's what they made the

comparison for. I'm pretty confident they pretty

much touched on every point. Nimish can step in

any time he feels like. But I think they did a

pretty good job of addressing every change,

almost nearly every change, except for maybe

there was some cleanup, you know, changes that

were made that we didn't address in the

comparison. But for the most part, I think they

did a good job of going after the major concepts

and addressing them.

MR. PUROHIT: We looked at all the areas

that had the comments. That's why I kind of

redid the comparison document and added common
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

325

areas from the TGWG draft as well. And as the

commissioner said, we kind of grouped it into all

the major changes that you had in there. We

didn't include every single change, and

especially there are areas where they're repeated

throughout the document. Kathi brought up the

constant reference to 542, that was throughout

the document. There was some other issues like

the Tribal Gaming Regulatory Authority being

truncated to the TGRA. Even though they were

major and throughout the document, it's kind of

implied that that's more of a verbiage change or

something along those lines as well. But the

major areas the commissioner said that had

significant response associated with that as well

and the reasoning by the TGWG, those are the ones

we grouped in there and those ten areas that we

highlighted.

MR. WILSON: And I think for us, some of

the confusion with that document was that it's

honing together different sections of the

standards, but losing track that, oh, wait a

minute, this is talking about this section, this

is talking about that, but it's all grouped

together. And the other thing that can be a
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

326

struggle sometimes is when it just pulls out,

let's say section E, but then it begs the

question, what's in A, B, C, D prior to that and

what's after it. And so we're all understanding

better now that there's a bigger piece here that

as a TAC we have to reference so that we're

seeing it in context of an entire document and

not just the piece that's on the display.

MR. LITTLE: You know what will be

helpful, because we're going to get into the MICS

today hopefully, and we've done some comparison.

That's a little different than this comparison

document. But it would be really interesting,

because we've got our attorneys and our audits

going through that document trying to prepare a

good document. So if there's any suggestions

that you have, if there's a formatting thing that

you can suggest, please let us know now because

we're hopefully going to have that entire

document to you over the next few months as we

continue along as it goes on the agenda. So if

there are some formatting or agenda issues that

you want us to talk about, please let us know and

we'll get that in there.

MR. WILSON: Thanks.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

327

MS. HAMEL: I just have one question. The

review process that the NIGC is taking for the

MICS, is it being reviewed by a group of people

collectively or individually, and different

people are making different comments based on the

section?

MR. LITTLE: Primarily it was done by our

audits department and Rust West, who is here, one

of our senior auditors. He'll be available,

certainly like Nimish is here, to help clarify

some of the, you know, reasoning or the comments

that we made. And, you know, once again, you

know, we're looking at it from our perspective.

Some of the things in the document, you know, we

think probably could be clarified, and these are

just our comments and, you know, the way we're

looking at it. And, you know, take it any way

you want. And, hopefully, it may stimulate some

discussion, and if there's some areas where we've

got it wrong and where we are not sure or we've

misinterpreted the meaning of the TGRA, please

let us know. So it's basically just a starting

point for discussion, not a position, not

anything, just how we perceive this. And the

hope is that, you know, it will stimulate some
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

328

good discussion and then it will help us have a

better understanding of what the goal of the

overall change is.

MR. McGHEE: So can we suggest maybe like

if we're going through these substantive changes,

the big changes -- I've only had them a few

months -- but if you go through those, and then

like we talked about yesterday, then if we get

through -- I mean, you guys' comments. And then

the other things that weren't addressed, if we

save time before we move to a new section to say

any other issues within the bingo section that

weren't changed, weren't made to that, we

actually give the opportunity to address those

each time. Like we're going to do with the

technical standards today, there were parts that

weren't changes made, but people had some

questions. So we save that at the end of

each --

MR. LITTLE: We think the MICS was done a

little differently, and that is there were some

areas that weren't addressed by the working group

that we have addressed in our working group.

That's why it will say, No comparable section.

MR. McGHEE: If we deleted the --
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

329

MR. LITTLE: Right. That could be true,

you did do a good job at streamlining the whole

thing. That might be an opportunity to say why

we did this, this was the logic and reasoning.

MR. WILSON: Thanks.

MR. FISHER: Sure. I do have a -- I guess

I have two questions. One is what is it that you

want to project up on the screen? Do you want to

project the NIGC document, or do you want to

project the TGWG document? Because the full TGWG

document that was delivered to NIGC has

everything in it, plus the changes, plus your

commentary.

MR. McGHEE: I think the summary that has

been --

MR. FISHER: You want the comparison

document?

MR. LITTLE: My opinion, and I thought

this worked out well, when you did put the

working group's document up there and then as

topics came up and edits were made, you were able

to do it right there. I thought, for me, that

was the most beneficial. We all have the summary

documents and we can certainly get everybody a

hard copy if they don't have it. But for me, I
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

330

thought that was most helpful when you could

actually sit there and make the edits and get the

changes, and that way everybody can look at it so

when you're back in your room late at night

saying, What did they say, we make sure

everything is correct.

MR. McGHEE: Did you have up the TGWG,

this document?

MR. FISHER: I have both things. When we

were kind of looking at different sections and

how the sections fit together and then when we

made a change from what was in the -- what was

contained in the comparison document, I made that

directly -- I was working in the TGWG document.

MR. McGHEE: I think the way you were able

to toggle just the two documents --

MR. FISHER: Back and forth.

MR. McGHEE: Is the two you're only going

to need. You can pop this one up or pop this one

up.

MR. FISHER: Okay. That's good. We can

check at the end of the day about how you handle

the executive sessions in the morning, whether

you want everybody to come down or whether you

just want to do the executive session and then
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

331

say we're going to start a half an hour later or

an hour later, whatever it is.

The second thing is I realized last night

when I was going back through the consensus

decisions and trying to figure out how to capture

those in a way to give them back to you, and I

don't have them for you because I haven't figured

out how to do this yet, so here I come to tell

you that the -- two things, one is the thing that

you pointed out, Tom, which is that there are

other changes in the TGWG document that are not

reflected in the comparison documents. And,

secondly, that the -- that it would be, I think,

really useful for the TAC to designate kind of an

informal or formal, whatever you want to do, just

if you want to call it a drafting group or

whatever, to really begin the process of thinking

about how your -- what your final product is

going to look like and then to work with us

around how we capture the consensus decisions in

a way that will feed into the final product. So

I'm assuming that you're going to have -- you're

going to reach consensus, you're going to issue a

report. And as I was looking at all of the

consensus decisions, there are some choices to be
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

332

made about how to organize it and how to present

it. And rather than me make those choices, I

thought if you're up for it, you could --

somebody could work with me around how we capture

that now, or we can just put it out to you and

you can deal with it later on.

MR. McGHEE: I mean, just so I'm clear,

let's say the technical standards are almost

done, except for definitions, which we're

supposed to address as we go along, I understand.

So you're saying maybe a group could take that,

not necessarily to make changes, but decide this

section would work better here or that kind of

thing, when you're talking about formatting it?

Because what would that group do with the

technical standards after we're done, with what

we just had?

MR. FISHER: There's some questions on

what's the best way to organize the presentation

of your consensus decisions. And because if you

did it by the comparison document, the comparison

document mixes different sections, and so there

are some choices around if you're going to do it

section by section or if you're going to combine

sections like we did. And so I -- it would be
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

333

useful for somebody to be thinking about what's

the best way to present the recommendations in

the final report.

MR. McGHEE: Like the notes versus

substantial changes or suggested language versus

a note versus --

MR. FISHER: Right? So, anyway, that's --

as I was trying to do the work last night around

that, that's what I discovered. Think about that

and we can come back to that later on.

Okay. Any other comments or reflections

about yesterday's work that anybody wants to

share before we go back to the technical

standards?

MR. McGHEE: Do you think -- I know in the

agenda there's a spot for definitions kind of at

the end of each thing. But since today, we're

going to be done with these technical standards,

wouldn't it be more helpful to go ahead and look

at all the definitions of the technical standards

and be done with that document? There's really

no comparison document, I don't think,

summarizing the definitions. We didn't really

look at them. So before leaving technical

standards, let's maybe look at the definitions.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

334

Because I would rather say we're done with

technical standards and wipe our hands of it. If

everybody is okay with that. Instead of each

time, you know.

MR. FISHER: Yeah. That's --

MR. McGHEE: I don't think there's a lot

of changes, but there are changes people should

be aware of.

MR. FISHER: I just put that on the bottom

of that list. That's the list that I was

informally tracking of the things that got raised

yesterday that we said we would cycle back to.

So I think it's a good idea to finish off the

technical standards in its entirety before we

move on to the MICS. So if we want to make sure

that -- we want to make sure we cover anything

that anybody has on the technical standards

before we finish with that and move on to the

MICS. I may not have gotten this list entirely

complete, but that's what I was tracking on the

informal list. And there were a couple of other

things, that issue around the grandfathered

provisions and whether we need to make some

statement about what's included or not included,

be more explicit about that.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

335

Are we ready to pick up there, anybody

have anything else before we start? So is that

the right place to start? Some of the things on

the list, Kathi, were things that you had raised,

but maybe it might make sense to start at the

beginning of the regulation and just go through

it, kind of section by section and see if anybody

has anything in Section 1 or Section 2 and just

try to do it that way? I don't know where your

questions are, Dan.

MR. LITTLE: I said downloadable software.

I want to talk about remote access. And there

has been an issue. It is -- do the TAC folks

feel that the technical standards address this

issue? I mean, does anybody have any issues with

it? From what I've heard, there's been some

issues where tribes have not had an ability to

remotely access servers, and that has become a

problem in the audit.

MR. PUROHIT: I'll rephrase it. The

servers -- the manufacturers, when they come in

and remote access the servers located on tribal

land and vice versa, when you're in a wide area

network where multiple tribes are participating

in -- like I'll use an example that I use
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

336

sometimes. Let's say Chickasaw Nation is hosting

a network of games that has 200 terminals for a

manufacturer, and then some of the other smaller

tribes in the neighboring areas because they

can't really have the propensity to fulfill the

two player minimum, they'll go into the wide area

network as well. So one of the issues that was

constantly bringing up to our attention is the

other tribal regulators going into this wide area

network while the hosting tribe has the ability

to go in and verify the software, the signature

and everything else on demand like they need to

on the regulatory side, the smaller tribal

regulatory authorities may not have that access

to go and verify the software because the main

software is not located on their land. Has

anyone else of the TAC experienced this? What's

been your experience in general with scenarios

such as these? Is this something that's echoed

by the smaller tribal jurisdictions that are

hooked up into these wide area networks quite

frequently?

MR. MORGAN: I have a question, and it's

maybe where would this conversation be

appropriate. Technical standards are
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

337

capabilities of the system. Your discussion

you're bringing up is does a TGR have the ability

to go in and verify software which seems to be an

internal control, or is that outside the realm of

technical standards question? That's what -- the

that's the question that comes to my head.

MR. McGHEE: To verify software signature,

stuff like that, which is sometimes a requirement

normally in the regulations -- I mean in the

MICS. And then if what you're saying is -- and

the question I would have if I'm responsible to

do that, and which our tribe -- I don't think we

go that far out, I'm not sure. The question is

do I rely on the host tribe to tell me, hey, have

you checked that, therefore I'm in compliance now

too because I can't check it, or you're saying

each tribe that participates should have the

ability to check it?

MR. PUROHIT: It is a technical standard

because the signature verification, if the

software is not there for you to access, what are

the requirements of doing that signature

verification. That's what it is. Like does that

need to be reworded for --

MR. McGHEE: What you're saying is we have
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

338

to put something in the technical standards that

the systems should be capable of allowing remote;

not necessarily do it, but it should be made to

where it can be done?

MR. PUROHIT: How can it be done in those

situations for networks.

MR. MORGAN: So but these requirements are

something that's placed upon a manufacturer. So

the manufacturer has to build their system in

order to be capable that it has to self-verify,

one; and then, two, that it provides some type of

signature verification format so a TGRA can come

in. And your question revolves around, you know,

does Tribe B advocate ability to go in and

signature verify something when everything is

located on Tribe A's property? Is that not a

contractual matter? I mean, before you approve a

game to come in and you're looking at can I do

this and your questions that you have at a local

level, and if he says, you know, you're not going

to be able to verify that because actually where

this server is located is off your jurisdiction.

It comes into question -- because I have

jurisdiction over my gaming facility. What if

they put that server in the tribal headquarters
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

339

building that's tribal lands and may be eligible

for gaming, but I don't have jurisdiction there?

It's still that question. So the question would

be to me is would I allow it to be placed there.

And if I'm in the position where I don't need to

play the game unless I do, well, that's -- I'm in

a different position other than maybe I could

take it or leave it. And if I need to put it

there, then either I'm doing some discussion with

the manufacturer, I'm doing a discussion with the

operator, and I'm probably doing a discussion

with Tribe A's gaming regulatory agent how do I

accomplish this. But I still don't see how this

becomes a technical standards issue. Maybe this

has to be a manufacturer.

MR. PUROHIT: I'll give you a common point

to that. What about the fact that they're saying

that just by putting it somewhere else, they

don't necessarily have to abide by the

capabilities. Because it's not there for the

tribal regulatory to go in, should there be

something in there that says we have the ability

to have this actually go in and verify the

signature on this. Even though it's a minimum

requirement, is there something that because now
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

340

it's in a wide area network setting, does that

bypass that requirement from that perspective?

Is there any kind of issue for that perspective

that you can only go in and verify the software

in person? I don't know if that makes sense or

not.

MR. FISHER: I don't know, Tom or Daniel,

whichever one is first.

MR. WILSON: In the private industry, we

deal with these issues in the public accounting

world, anyhow, when we're doing audits of things

where we're relying on somebody else, somebody

else to certify that the controls are in place

that we can't physically go verify. So it's

called SAS 70. What that is is that I make a

reliance on this other tribe somehow certifying

that the system, the signature verification,

whatever the issues are that the controls that we

normally would test ourselves, that we're relying

on a statement, you know, some form or whatever

from that host tribe that they, in fact, have

complied with and that, you know, the signature

has been verified, whatever it is, and that

that's how we would address getting assurance

that that host tribe is in fact doing what
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

341

they're supposed to be doing and certifying that

they're meeting the control objectives that we

would normally test for, the same thing if we had

that system sitting right in our shop, so to

speak.

MR. MORGAN: Is that internal control or

was that a technical standards?

MR. WILSON: Well, the -- the technical

standard aspect -- well, that's an internal

control. So the technical standard, the

technical standard is that, you know, it has to

have the capability to do the signature

verification. The control is that, you know, I

need a mechanism to rely on you as the host tribe

to ensure that you are following the controls

that are supposed to be in place to protect the

integrity of that game. So in my mind, the

component or the SAS 70, whatever you call it,

that's a component you get through as a control

mechanism. But there wouldn't be anything you

would say in the technical standard because the

expectation is that it doesn't matter who's

hosting that system, it meets the technical

standard. And I'm just relying on your

certification that that's so. Because I can't
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

342

physically walk over there and verify that.

MR. FISHER: Let's do Leo, Matt, and then

Nimish.

MR. CULLOO: I think the control standards

you're talking about are contractual. I think

those would be in the contract itself outline

everything that they will adhere to in their

compliance. So to me that's more a contractual

item than it would be anything else.

MR. MORGAN: I kind of agree with Leo.

And the example I would bring up is in the Class

III world, your WACs, Class II world, Rocket.

The server sits on her land, secondary server

sits on my land. The old Megamania game where

you had one ball draw that came up and people

participate in it. At no time did all those

tribes in there have a chance to go in and say, I

want to verify the balls coming up from the ball

blower. You relied on whoever is hosting it to

perform that function through a contractual

manner when you sign on, because some of it is

how bad do you really want this. To impose that

additional cost on the manufacturer to say not

only do you have to let where you place it be

able to signature verify it, now you're going to
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

343

have to come up with the capability to let remote

access tribes who may be participating in the

game -- because Class II, that is what it's all

about, multiple participation -- you're going to

have to come up with that component to allow

everybody else to -- it's either got to be you

set up some internal controls to address that and

you address it through a contract. I'm failing

to see where the technical component comes that

makes me feel that --

MR. PUROHIT: Well, the follow-up is also,

you know, we talked about another requirement

yesterday with the downloads. What about the

issue for -- once again, that also goes to the

MICS side as well. What about the issue of the

verification of downloads, that's something that

still needs to happen. If a manufacturer is

going in verifying that, that they do some kind

of a download, they push out all these updates,

what have you, where is the capability going to

lie there? Are they still responsible for making

sure that that one server still adheres to all

the requirements as far as the technical

standards go? And, you know, it sounds like

everyone's input so far is that's going to rely
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

344

from a MICS perspective and a contractual

perspective, that only that one tribe and one

tribal regulator is going to be responsible for

it and that kind of extends to other tribal

regulators participating in there, depending on

the contract.

MR. CALLAGHAN: I do have a Class II wire

contract here, and it does have all those terms.

It has they have to adhere to tribal rules and

regulations and applicable federal law.

Agreement to regulation, supervision of game

operators, which would be the Four Winds. Tribal

gaming authority. So all that language as you

mentioned is in here, and we do have the

authority to go and verify if necessary, and we

also have the option to void it as a regulator as

well, void the contract. Similarly -- and

there's similar language in the other -- in wide

area progressive contracts as well. So I feel

like the controls are there for me as a

regulator. Being sympathetic and empathetic to a

smaller tribe who may not have the ability to go

physically and do it, it's still in the contract.

And then there's that decision, not a commercial

decision but a regulatory decision, that decides
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

345

whether or not I'm going to allow that game on my

floor, irrespective of the environment.

MR. McGHEE: Or the host tribe you provide

the information and trust them.

MR. CALLAGHAN: And I do believe with

downloadable. But we've got some market things

where we can verify signatures through our

checks. And when they come into our system, I

know I've been in touch with WMS, a little to a

degree with IGT. And we have the ability to

verify signatures similar to what we talked about

with parity checks and things like that. So

there are internal controls that will be in place

for that.

MR. WHEATLEY: I could see some value in

having a technical standard that allows a tribe

to be able to do that, signature check on site,

even though software is coming from off of their

land. I mean, we're a field trial site for

Rocket gaming, so essentially I'm getting new

software every week. So for my Tribal Gaming

Regulatory Agency to have to call another host

tribe saying, hey, can you verify this signature

for me, it's going to be a constant type of

thing. I don't know, is it that big of a deal
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

346

for a manufacturer to be able to provide that

type of ability for a TGA to be able to verify

the signature of the software at a remote site?

I don't know.

MR. MORGAN: My question is to Nimish.

Doesn't Jeff still have the ability, though, to

verify a software at the terminal level? The

report says here's the signature. You can still

go to the terminal and look and say, Does it

match. Even though he can't physically go in and

signature it at the server level, he can still go

through it at the terminal level.

MR. WHEATLEY: As long as I can do it at

the secondary server level, I think that would be

fine. I thought that's what we're saying is not

available.

MR. PUROHIT: Exactly. The secondary

server, that will still have the critical

software, for example. But what about like the

issues where updates are being pushed out to the

software and having those updates be verified as

well? It's like a two-step thing. You're not

just verifying the critical software at one end,

but once the updates are done that the critical

software is still untouched and you can go verify
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

347

any of those updates as well.

MR. MORGAN: But when you update software,

it changes the signature. The lab or the

manufacturer are required by tribal law

regulation to send that to every jurisdiction

that has it. You get a report that says, hey,

your signature went and changed. You can still

go out to your terminal and look and say, yes, it

did or, no, it didn't. You may have to get on

the phone and call whatever tribe has that server

and say, did y'all go check the server too and

make sure. This almost reminds me of, I don't

know, taking a shotgun approach to something that

may be able to be fixed with just a phone call.

That's a phone call, we're there. Tom's brought

up the expectation in internal controls to solve

it. I'm still failing to grasp how an additional

technical standard remedies a situation that

seems to be there's already solutions out there

to remedy it. It may not be my sole -- I can't

do it solely within my own place, but there are

remedies out there.

MR. WILSON: I think, you know, me as a

regulator, the risk is that the -- I'll call it

the host tribe, whoever is hosting the system,
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

348

isn't doing what they're supposed to be doing and

that they have, you know, verified the signature,

they verified the download. And so it's more

important to me to want to have a mechanism to

hold them accountable for doing that, which I

think is through the MICS, probably, that defines

-- probably there's not a formalization of this

concept of a host and the host having a document

prepared that they provide to hostees that says

we are doing these things. And so for me, the

risk would be I would want the MICS to reflect

that that's a requirement if you're hosting the

system, that you have to do A, B or C. Then the

technical standard -- because the technical

standard -- the mechanism to ensure that is not

through the manufacturer. It's from tribe to

tribe through an internal control issue.

MR. McGHEE: Similar to along what you

were saying, if it were me and I knew that the

host tribe was them and my concern was whether or

not they were verifying the signatures when the

downloads happen and they're capable of doing it

because it's on their property and I'm not,

probably prior to a contract coming up, I'd want

to contact that investigatory agency and say at
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

349

least let me see your procedures; do you have

procedures in place about how you test your

signatures and updates happen, make sure I'm

comfortable with them before I would enter or

approve the operations entering into a contract

with them. And then at any point, like I was

saying with this contract, I was making sure that

I could go in if I needed to do that site because

I think there's an issue that, you know, this

regulatory agency is not comfortable with the way

you're doing things, people at my place --

whatever the issue, that I could go in and do it

myself. Which would fix the problem of what

you're saying. It doesn't make it easier, but --

am I right? If I did it that way, that would fix

the problem and what we're trying to accomplish.

Maybe not the way in which you're suggesting it

being accomplished, to make it easy.

MR. PUROHIT: I'm trying to put feelers

out there what's happening with this issue,

because we keep getting it all the time from the

smaller tribes.

MS. HAMEL: My question is, and maybe it's

because I don't understand because it's way

techier than I am, but if there's Tribe A is
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

350

hosting the server, there's an intermediate

server that has the signature. I'm not aware of

any system where there isn't a signature on the

property that's offering the prize. So the

verification -- and if I'm wrong, please correct

me -- always takes place on the property that's

offering the prize or the WAP or whatever. I

don't think there's just a remote connection

without any intermediate verification. Is that

true?

MR. McGHEE: There is no remote section.

That's what he's suggesting be in place.

MR. PUROHIT: The question was revolving

around -- so the intermediate servers -- let me

ask a follow-up question to that. I'm trying not

to get techy either. Does it just host -- does

it just have a signature available when the

tribal regulator for the local jurisdiction wants

to pull up that signature, or is it capable for

them to have that intermediate server talk to the

main game server and then run the signatures to

whatever the local tribal regulator wants to run

the signature in, as the technical standards lie

right now, using whatever methodology that they

want? Is it something that's saying that, oh,
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

351

yeah, the signature is done; is that what the

local server is saying, or is it giving them the

access and saying, here's access to the main game

server content, you can do the signature however

you want to do it, as one of the requirements of

the tech standards?

MS. HAMEL: It's my impression if those

two signatures don't match, they won't work.

MR. FISHER: Okay. I think we have --

MS. HAMEL: And it can be verified.

MR. FISHER: -- Jeff and then -- it might

be easier to go around that way. Let's start

with Jason.

MR. RAMOS: I guess my question, Nimish,

is in the Class III world with either the IGT

server-based games or wide area progressives, I

don't have any server-based games, but I know

with the wide area progressives, we test the

machines on the floor. But IGT to my knowledge

doesn't give us access to go back to their main

server to test that, so I think there's a

comparable world in Class III where we're testing

it on the floor.

MR. PUROHIT: The wide area progressive

one is not a comparable example in this case,
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

352

because like in your case, it's wide area

progressives for the Class III --

MR. RAMOS: Say it's an IGT server-based

game. That is a Class III game. To my

knowledge, they don't allow you to go back in

their main server to verify the software.

MR. PUROHIT: Right. It's a -- you're

talking about SBX, for example. When the content

comes installed on the actual game, everything is

happening at the terminal level now. In this

particular case, on the game server itself,

that's where all the math models and the pay

tables reside. So giving -- I'm trying to give

you a comparison. I'll use an older fashion

model as well. In the wide area progressive

setting in the Class III world, IGT, for example,

they can't send a -- and I'm just really

trivializing -- but they can't necessarily change

something on the server side of it that it will

change out the math models for all participating

terminals. That control resides at the terminal

itself. So that's from the risk perspective,

that's where the risk resides. That's why I was

asking that question.

MR. WHEATLEY: I'm with Kathi, I don't
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

353

understand what the issue is because my

impression is when we get new software, it comes

with the lab certificate that says, you know,

this is the signature of the software that's been

tested by the lab. And even though we're not the

host tribe, we have the secondary server on site.

And I'm thinking that we have the ability to

verify that signature that the software that they

say that they're installing at the host tribe is

the software that's being pushed down to our

site. So I don't know if that's not the case,

but it seems like it's the case to me.

MR. MORGAN: I'll agree. If you keep in

mind, there are several servers running at any

one time that control certain aspects, whether

it's the ball draw, whether, you know, your back

office system. So it's multiple servers working

together. And I'm going to try to help you out.

Mr. Acting Technical Training Director, is it not

an educational effort that needs to happen here

because people don't quite understand the setup

and makeup, especially in Class II, of how these

ball draws work? There is a main ball draw that

comes down to a local level to a subserver before

it comes out on the floor, and this is how you
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

354

would handle that. It seems like there's a

misunderstanding of how the system works, and

it's opposed to -- there's a problem out there

that manufacturers need to go fix.

MR. PUROHIT: We'll try, Matt. It's been

part of the Class II training effort.

MS. LASH: I just wanted to say I think

it's valuable to have this conversation, at least

for the Miami. We're a small tribe and we were

just approached by a manufacturer do the wide

area ball call, and the host is in Montana. So

we're facing these same issues as far as what is

that tribe's security parameters for that server

that we probably won't ever see, and, you know,

the testing and all those issues. We're looking

at that. Because conceptually, it would be a

good idea for our small hall to not have to sit

there and wait for two people or have one person

play two games so they can play that system. And

there's 16 tribes right now that are linked to

that host out of Montana, but we have other

issues as well, you know. And I've asked, and

this is just what are the complaints from

management as far as the signals; do you have

signal lapses and how frequently and those kind
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

355

of things. Because it will swap back over to our

server when they say they'll be a temporary, so

we just have a lot of questions right now.

MR. CALLAGHAN: That's ironic that you

mentioned it because I'm looking at -- I'm asking

the casino to have the contracts looked at as to

see when we lose communications, we're in a wide

area progressive, there's still going to show the

last WAP on there. If that jackpot were to be

hit, who's going to be responsible for it. It's

a risk. So adjunct to that is how much cradle to

grave do you think needs to be on technical

standards. I would suggest you take a look at

Nevada, numbers in Nevada as a parallel, which

you're probably going to be doing. Because with

Nevada numbers, it's a keno system. But the

server is resonated in a business in Las Vegas.

And quite frankly, if you looked at where they

keep the server and who's watching over it, other

than the camera, you'd be a little surprised.

This is the Class III world in Nevada which you

think would be pristine, not meaning to cast any

spurs, but it's kind of interesting to see. So

you got to take a look at it, how far do you want

to drill this thing down. On the downloadable on
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

356

Class III, as I understand it, they download the

game, it's got to be through a separate server.

It can't download directly to the games. So you

download it to the server, then you verify the

signature. I think it would be helpful, and

maybe it's too late for this now, but I'm a

visual guy. I wish we had a schematic up there

and literally a schematic between Class II and

III because there's so many things as we

discussed before, the ball drop, where the server

is, where does the card draw come from, and take

a look from there.

MR. FISHER: So is that possible?

MR. LITTLE: He's probably already trained

on it.

MR. PUROHIT: I have a schematic, just not

on me right now.

MR. FISHER: If we could figure out how to

get it. Tom.

MR. WILSON: Nimish, I just want to be

clear that I understand the risk that you're

trying to describe. Is it that on the host

system, there's a download, updated software or

whatever, on the intermediate system which is

communicating with the host system; is the
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

357

concern that there's only a one-time signature

verification that goes out to the intermediate

system and now that's sitting static, but there

could be a new signature verification on the host

system? So in other words, if the two systems

are in communication and if the host system any

time there's a download changes signature, that

automatically updates the intermediate system so

that from that terminal you can verify the

signature if you so choose; is that what the

concern is?

MR. PUROHIT: The concern is that -- I'll

put it like, you know, give you an example using

Class III terminology and any other

terminologies. You're asking the system, only

the primary host, for example, has the ability to

do signature verifications on demand. And the

secondary, the smaller tribes that have the

intermediate server are relying on the system to

keep itself honest and pulling it that way.

While they can't go in and use -- generate the

signature that they want using any other tools

that they might want to do as well. I don't know

if that makes sense or not. It's like saying you

go up to a gaming machine, you go up on it and
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

358

you go up to the menus and the gaming machine and

tell it, give me all the signatures that you have

there. So that classic idea is you're asking the

machine, are you still good. Generate your own

signature, show me what you got. That's the

idea. As opposed to pulling up the media and

then running the signature by yourself with

whatever tools and methodology that you want.

It's that -- the concern that I was trying to get

some input on in that particular area. I don't

know if that makes sense.

MR. WILSON: But cannot -- if -- I mean,

it seems to me the key issue is, is the host

system providing the signature information to the

intermediate system in realtime. And if that's

the case, how a tribe gets to that information is

a different issue. The technical standard in my

mind is that that communication protocol, you

know, that that realtime updating or that that is

happening, that's the technical standard that

that has to occur. But how a tribe actually then

verifies or chooses to come to how are we going

to verify whether we're relying on a

certification document or whether we can at the

terminal do something, that's a different issue
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

359

than the technical standard issue. I mean, my

concern from a technical standard would be that

that communication protocol, or that the inverse,

that that intermediate machine wouldn't be

updated with the current signature when there's a

download on the primary host machine. To me,

that's the technical standard that if the risk is

that, that you would want to make sure is it

current, but not how one goes about verifying.

MS. HAMEL: Well, my question is, Nimish,

is there not a signature on this intermediate

server? Because to the best of my knowledge,

there is. That can be verified.

MR. PUROHIT: Right. There is a signature

on it. But the issues that have come up as the

tech standards are right now, it says that the

TGRA has means to check the signature with

whatever methodology they choose. And that gives

some examples of the methodology. And that's

what I'm trying to get a feel for, is does that

choice exist for the participating smaller

tribes, for example, or are they just relying on

the fact that this is a signature that's being

pulled up at that secondary server, and here it's

a pass? Once it's actually built in after they
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

360

approve the software and everything else. And it

definitely sounds like this is moving into more

and more of an internal control arena here as

well, as far as that choice -- it might just be

whatever that they agreed to, that they can go in

and verify it later on, as opposed to presenting

a choice of using whatever methodology.

MR. FISHER: Sounds like that's the

message you're getting. We'll keep going around.

Leo.

MR. CULLOO: Again, I think there's a risk

in everything, but you mitigate it by taking

steps through your internal controls. So you

have a contract that specifies what they have to

do to be compliant. You also, in our case, our

TGRA sent a letter out to all the manufacturers

which we have area wide network, you will give us

written notice prior to doing a download or an

upgrade; you will give us 24 or whatever,

48 hours with the information on what it is and

what it's going to accomplish and their

signature, and then they get they go to the

machine and they do their signature. So I feel

we've mitigated our risk as best we can by taking

those three steps.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

361

MR. MORGAN: I guess to conclude, what I

keep hearing is there is some misunderstandings

of how Class II systems work that exist in Indian

Country, so that probably could be addressed.

Two, you always have the ability through a

contractor, if you don't like the terms of the

contract, don't enter into the contract. Because

when you say do you have a choice, I don't get to

go in and say, you know, this is going to be

verified through a CD versus a flash. I mean,

it's a choice of do I want that game software and

is there an independent third party verifier

system in place that I can go in and check that.

I don't actually get to go in or -- I don't think

anybody gets to. I mean, I'm sure they take

people's opinion. But it kind of goes back to

how big are you. The bigger you are in the

industry, the more requirements that

manufacturers will bend to you, and that's just a

numbers game. When you're very small, you don't

have that leverage. When you're very big, you

have more leverage to get things done that fit

the way you want it to get done. But at the end

of the day, it's always a decision of do you want

that. Because if you don't want it, it just
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

362

doesn't come in your facility. And whether

there's a tribal government decision or an

operator decision or a regulator decision, if

everybody is not happy with it, it doesn't

happen. And, you know, as far as I know, I mean,

Class II servers have been running well since

'96, '97. And that's the reason I think a lot of

it is an educational effort that may need to take

place for people that don't quite understand the

setup of how this works.

Back to Brian's point, maybe schematics

would help make sure that people understand

exactly how that information gets from the

manufacturer to your game floor.

MR. FISHER: Okay. Nimish.

MR. PUROHIT: Just a follow-up general

question, then. It's relevant to this

conversation. Simply put then, you know, are the

current standards for signature verification that

we have, technical standards, are they sufficient

enough to address wide area networks? That's

pretty much what we're trying to get at here as

well in general. Okay.

MR. WILSON: We could vote on that.

MR. FISHER: You could make a
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

363

recommendation that says don't change it, it's

fine.

MR. MORGAN: Nimish, the one thing that

may help the Class II MICS, that's one area of

MICS that has gone forward from the Class III

MICS, but because they've never been made

effective, maybe once you get to that, maybe that

will address some people's concerns. There are a

lot of things that empower the regulator on the

Class II MICS than on the previous Class III

version.

MR. McGHEE: Is that one of those

questions on your sheet that you wanted to ask?

MR. FISHER: Did you have other questions?

MR. McGHEE: I'm saying maybe if that's a

specific answer they wanted, maybe it should be

some kind of a formal answer.

MR. LITTLE: We're not asking for a

specific answer.

MR. McGHEE: You're asking for a specific

something. Whether we like it or not. Do you

want it on the record that we said we didn't like

it?

MR. LITTLE: No, that's not necessary.

This is a good -- it's a learning process for us,
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

364

and, you know, it's important we're making our

decisions and, you know. We go through that we

can, you know, Nimish will be very helpful to the

commission and these are complex issues. And

everybody doesn't know everything, but that's why

this group is so important.

MR. PUROHIT: These are questions that

come up both in training and consultation.

That's why we wanted to ask the TAC as well,

what's been your experience with that. That's

the main reason for asking these questions.

MR. LITTLE: Like I said, we're trying to

create a regulation that encompasses the entire

industry. And you guys are diverse. And it's a

tough task, a tough task that you all have and we

all have.

MR. FISHER: Did you have other questions

you wanted to raise now?

MR. LITTLE: I think the only other ones

are basically are there other areas that need to

be addressed that weren't raised.

MR. FISHER: So maybe we should just -- I

know there are some things up there that we said

we would cycle back to, but what if we started at

547.1 and see if anybody has anything that they
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

365

want to raise or question and go through it. Or

you want to start with those?

MR. McGHEE: I would say based on my

experience with going that way, you start putting

out things that you never would have -- I mean,

it's giving the chance we shouldn't. To me, it's

your job on this committee to study that and know

that you have issues prior to coming. So I would

just say are there issues, like Kathi has done,

she has already named her issues throughout the

document that she had. Going line by line is

going to stretch it, and we'll be here all day.

MR. FISHER: I wasn't suggesting that.

MR. McGHEE: Section by section, either

way. Just my suggestion.

MR. FISHER: This is an opportunity for

people to raise anything that they have in the

technical standards that hasn't been covered yet.

So whatever the best way to do that is, that's

how we should proceed.

MR. McGHEE: Does anyone disagree with

what I'm saying?

MR. WILSON: No, I think it puts the

ownership on individuals that they should have

reviewed the document, and if they have an issue
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

366

with something, they need to bring it forward.

MR. FISHER: Where should we start?

MS. HAMEL: I have 547.7(c). We talked

about (c) as number one.

MR. FISHER: I have the published one on

here. Do you want me it pull that up?

MS. HAMEL: That's okay. Isn't it still

(c)? Submission, testing and approval. 547.7.

MR. PUROHIT: That's hardware.

MS. HAMEL: 547.4(c)(1).

MR. McGHEE: Submission, testing, which is

still (c). So Page 10 of that document.

MS. HAMEL: It says the Class II gaming

system.

MR. FISHER: There's page -- there it is.

Right. Got it.

MS. HAMEL: (c)(1).

MR. FISHER: Right there.

MS. HAMEL: The Class II gaming system

cashless system, voucher payment system or

modification has been submitted to a testing lab.

It's my understanding that this goes all the way

back to systems, Class II gaming systems that add

their own ticketing, their own voucher system,

their own -- that maybe was not compatible. And
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

367

does this apply today to all cashless vouchers?

MR. MORGAN: My first is just a question

to you, Kathi. Are you referring to when Class

II systems first kind of came into the industry,

they were self-contained systems, kind of that

you could do everything in there; you didn't have

to have these different components and that kind

of came on later with Class III, is that what you

mean?

MS. HAMEL: Right. This is where it just

pops up in the document. All of a sudden, we've

lumped cashless system and now voucher system

into submission, testing and approval. And I --

I'm thinking it's something leftover from the old

days, but I don't think we submit these as part

of a Class II gaming system.

MR. WHEATLEY: You're talking about if

there's a third party ticketing system or

cashless system used, does that have to be

submitted?

MR. PUROHIT: I think it's an excellent

question, because I've been asked that a few

times by various, like, common, as they call it,

back-of-the-house system manufacturers. For

example, Bally, like, you know, if we have a
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

368

common back-of-the-house, do we require that to

be tested? Because it's not necessarily having

any interface with the Class II gaming system,

per se, only interfaces for ticketing, player

tracking, et cetera. And this, as I understand

it, was put in here for exactly what Kathi

pointed out, for those legacy systems that were

self-contained, as Matthew pointed out as well,

that had their own proprietary ticketing systems

where you could get a ticket like on Cadillac

Jack, print it out, you couldn't go and put it

into another gaming system's manufacturer and,

furthermore, you have to go to the cashier's lane

that had the Cadillac Jack window on there as

well. That's what this is geared towards. As

far as the standards right now and the intent, I

agree with you like the language is not

necessarily that clear, but the intent is that if

you do have that proprietary system which does

interface with all these other system components,

then that has to be tested as well. Anything

that's a common back-of-the-house beyond whatever

is outside of the self-contained system, that's

left up to the Tribal Regulatory Authority and

their systems' testing requirement which are
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

369

commonly known as interoperability testing. So,

for example, like, you know, Daniel, in your

jurisdiction, if you have like Bally 1, let's

say, and you have seven different system

manufacturers for Class II gaming systems,

whatever your requirement to be for that common

Bally 1 system manufacturer, they should submit

that to an independent test lab, and that should

be tested for specifically your seven systems and

diverse whatever you have and whatever your TGRA

requirements are. Kathi, go ahead. Oh, sorry,

Tom.

MR. WILSON: I was just going to say when

I pop back to the definition of Class II gaming

systems, and we talk about the definition, that

sounds like the definition takes into account all

of these components that what you're saying is

not intended in that statement. So it seems to

me that I have -- these are not very clear what

it doesn't include. Otherwise based on the

definition of Class II gaming systems, I think

what it's going to include that it includes all

of those things that Kathi is speaking to.

MR. PUROHIT: Kathi.

MS. HAMEL: My recommendation would be to
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

370

take out cashless system voucher payment system.

MR. MORGAN: Because you think that's

included already within a Class II gaming system?

MS. HAMEL: Right.

MR. McGHEE: You're not really testing it

anymore. You don't think it needs to be written.

MS. HAMEL: Because it's part of the

definition.

MR. PUROHIT: Does the definition of Class

II gaming system need to be scrubbed a little bit

to make that clear that it's referring to the

proprietary accounting?

MR. WILSON: The definition says all

components, whether or not technologic aids in

electronic, computer, mechanical, or other

technologic form, that function together to aid

the play of one or more Class II games including

accounting functions mandated by these

regulations.

MR. PUROHIT: Is that straightforward

enough then?

MS. HAMEL: I think it is.

MR. FISHER: There's also a definition of

Class II game, which is used in the Class II

gaming system definition.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

371

MR. WILSON: Above it is Class II game,

but it refers to --

MR. CULLOO: Class II gaming system.

MR. McGHEE: Do we need to do anything

about it?

MR. WILSON: We're going to recommend

removing that. I think we should test it.

MR. FISHER: The proposal is -- are you

removing it from one or are you removing it --

because it's also right there.

MS. HAMEL: It I think it should be

removed from all references.

MR. FISHER: Okay. Do you want to state

what the proposal is?

MS. HAMEL: Sure. I'm recommending that

any reference to cashless or voucher systems

associated with Class II gaming system be removed

from the regulations. Because the definition

encompasses those functions, those components.

MR. PUROHIT: And are you also

recommending removing definitions for that,

because there is definition for cashless system,

there's a definition for elite voucher or voucher

system as well, for both of them.

MS. HAMEL: Those are components. Maybe
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

372

used -- we'll have to see where it's used.

MR. McGHEE: If it's not used anywhere

else in the document, then, yeah, but we don't

know.

MS. HAMEL: If it's not used, I would

recommend removing the definitions. And I know

they reside in the MICS.

MR. WILSON: We're ready to apply it.

MR. MORGAN: While he's writing one point,

if you take that out probably from y'all's

perspective, I refer to that every now and then,

that the inoperability testing part of that will

have to become bigger in your training and

technical assistance programs. Because that is

that secondary component. It's important that

takes place that not actually required as a

technical, you know, that you want to be

certified and it runs correctly based on what you

submitted. Now whether it runs correctly in your

facility or not, it's not what the technical

standards are.

MR. McGHEE: Put part of the system as

defined, so you still have to test the whole

gaming system.

MR. MORGAN: I do inoperability testing at
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

373

my place because I want to make sure it runs

best. I don't use an independent testing lab for

inoperability. We do that ourselves. I just

want them to stress that it's still important

that that's probably the easier, best standard

that you do that, no matter where you get that

done, but I don't need that as a requirement in

the technical standards that inoperability is

done. You have to say does ACSC work. Yes.

Does Cadillac Jack's version of this game work

the way you get the signature. That doesn't say

does Bally 1 work with Cadillac Jack on Poarch

Creek's floor in the correct manner. That's not

what the lab will certify to. Unless you bring

the lab to the floor and you send them

configuration, and that's additional costs and

tests as opposed to what you're testing. I think

that will add confusion, especially for newer

people if they think I can send it to a lab and

I'm good to go on my floor. That's not actually

the case.

MR. McGHEE: Maybe you want to make

reference to somewhere, you know, which would

include?

MR. MORGAN: I think that's something for
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

374

them on training that they need to pick up on

training, not anything else.

MR. CULLOO: You left the word "gaming"

out of the Class II.

MR. PUROHIT: Does the Class II MICS have

any reference to a ten point test?

MS. HAMEL: It's not specific, but there's

reference and there's some guidance documents

that talks about testing.

MR. FISHER: Did I get that right? Did I

get that as you intended? Kathi?

MS. HAMEL: Yes.

MR. FISHER: Shall we test it? So if

everybody is -- if you support and agree with

this recommendation and yellow up on the screen,

raise your hand.

(All hands raised.)

MR. FISHER: Okay. All right. Great.

MS. HAMEL: Same section, 4(1)(b), we're

talking about submission, testing and approval.

MR. FISHER: 547.4(c).

MS. HAMEL: 4.

MR. MORGAN: (a)(1).

MS. HAMEL: Right there.

MR. FISHER: Yep. I got there.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

375

MS. HAMEL: (b).

MR. FISHER: Page 11.

MS. HAMEL: Okay. We've struck 542.

We've agreed to strike 542, and then there's

reference on (b) -- let me see. The following

will receive the testing report. Any applicable

provisions of 543 of this chapter that are

testable by the testing laboratory.

MR. FISHER: So that provision right

there.

MS. HAMEL: Is that specific enough of the

types of functions that need to be tested? Or

does that leave an operation with TGRA left to

say, okay, well, they should have tested player

tracking?

MR. MORGAN: It's definitely a catch-all

provision. I'll agree that is the intent. It's

kind of like we don't know what's out there, so

we're going to give you this broad language so

you can interpret it as a catch-all.

MS. HAMEL: That's why I bring that up,

because it's very, very broad and it could be

left up to interpretation and there could be

interpretations that important functions are not

tested. So does the TGRA determine what's
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

376

testable, or does the laboratory determine what's

testable, or the manufacturer?

MR. PUROHIT: I think the lead-in just

says TGRA therefore shall require the hardware,

software, manufacturer. Number 2, itself, the

regular number 2, not the Roman numeral, is that

-- I mean, is there confusion in there saying

that the TGRA is going to require that whatever

the following the Roman numeral 2, any hardware,

software that they are putting in. And the way I

would read that is if the TGRA wants any of the

further tests on there, they can require the

manufacturer submits something to an independent

test lab.

MS. HAMEL: Okay.

MR. PUROHIT: That's the intent. Is that

not clear in there?

MS. HAMEL: Well, it's vague. So I'll

just throw that out there, that it's not clear.

And what specifically -- even though there may be

changes in technology, there are some -- some

minimum requirements.

MR. MORGAN: I kind of have a thought, and

I'm not for sure what the recollection was.

Brian, your contract that you brought up --
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

377

because at one time when you started doing all

these contracts and the MICS started requiring

you to put a statement in there saying you're

going to follow all the tribal rules and

regulations, that that was a requirement when you

signed contracts with them. They wanted to see

that, whether this is development contracts or

participation contracts, they wanted to see

those. That's what that reminds me of, is that

TGRA, now you have to say, yeah, it was tested to

everything and you're telling us that it's still

good. I'm not for sure where the origin comes

from of that statement, but that's what that

reminds me of, is that type of statement from the

commission coming down that we want to make sure

that you agree that it was tested to everything.

Kind of who's on the hook for doing it, you know.

Kind of get -- they want to look to TGRA, we want

to look to operation, operation wants to look to

the manufacturer, manufacturer wants to look to

the lab. And that's that big catch-all provision

to say, hey, you did everything you were supposed

to do.

MR. WILSON: So the risk seems like -- the

concern is that the TGRA would not -- I mean,
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

378

you're comfortable that there are certain things

that no matter what, all things considered, need

to be tested. And that the TGRA, if they don't

-- if they don't know that, then just by not

spelling out some minimum, I guess, that the risk

is that certain things don't get tested that in

fact always should be tested. And this is

inherent risk, I suppose, in any language where

we talk about, you know, the catch-all, the

applicables. Because then it begs the question,

well, what's applicable, and are there some

things that are absolutely applicable no matter

what versus things that jurisdictionally may or

may not be applicable.

MR. MORGAN: You worry when you start

being specific that you're going to miss

something. So the way you guard against that is

you make a catch-all provision to make sure that

whatever is applicable or whatever you deem

appropriate is caught. Because if we start going

down and listing A, B, C, D, E, and somebody made

a mistake and we missed F, G, H, now we didn't

say it. Well, this is the way that we say it.

And some of these things may be, from a lab's

perspective, when you test what does BMM test
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

379

versus what GLI tests versus Eclipse versus

whatever lab you may use, because they all have

their scripts that they use to run through. But

I don't know what each script says for 547.

MR. WILSON: But maybe the issue is that

-- I mean, what I hear Kathi is saying is that

there needs to be guidance so that the

interpretation of this is understood that, you

know, by gosh, there are certain things that me

as a regulator, that I need to make sure are

tested for. And so that if there's some

guidance, for example, or something along that

line, I mean, that's the concern, yes?

MS. HAMEL: Absolutely.

MR. MORGAN: I would agree from the point

it's -- if your concern is something that's

absolutely necessary -- because, again, when we

talk about technical standards from a federal

level, you're really talking always about

minimum. And so if it's absolutely necessary

industry standards across the board, yes, we

should include it. But if it's something that

may be more specific localized, it may be

localized in a region, it may be localized at a

local level, it may not be appropriate that you
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

380

expand upon that here. Because we're talking

about federal minimum testing requirements for

manufacturers, and that's where I always go back

to the question of who's not understanding. If

that's from a regulator's view, I like to have

some leeway sometimes that I don't want to have

everything so black and white that this is all

you have to do because then you'll get in

arguments with other components, whether it's

operations or manufacturers. I don't have to

test to that because this is what NIGC says I

have to. You can always take the additional test

and add to them, but sometimes there are some

political structures getting that done. So

sometimes you want that ability to make an

interpretation at a local level. So my question

would be if we're missing something, what is it

here that we're missing that is a minimum federal

testing requirement? Because I don't know what

it is. And you're probably seeing something I'm

not seeing.

MS. HAMEL: I don't have specifics, but I

would just say that it is very general and it's

very broad. So if the determination then resides

with the TGRA, and our TGRA contacts the
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

381

manufacturer and say we want it tested and then

the manufacturer says, well, nobody else wants

that tested, that will be the push-back. You

can't ignore that that doesn't happen.

MR. MORGAN: Which we hear a lot.

MR. CALLAGHAN: The challenge we have here

by getting into specifics is how many years in

the making has this been. Matt, you discussed

the Nevada model. The industry can get together

and say we've got something new out here, a new

widget, we want a regulation written towards

this. Unfortunately, they don't have that

option. So we may be better served having it

broad, deferring to TGRA. And I've heard of that

before, nobody else asked for that. Well, guess

what? We do. If you don't, I have the ability

to say if it goes on the floor or doesn't.

Sometimes you can be surprised what can be

tested. So I think we may be better served

instead of drilling this thing down in today's

environment to be a little more broad to

encompass computerized aided changes that the

NIGC in the beginning, they thought computer was

old. Now it's super computers.

MR. McGHEE: I think it's important that
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

382

we clear it up, because I know there's like six

references to that same line throughout this

chapter. But I like how it's done because, for

one, it says applicable provisions, and then it

says and that they're testable. The only thing

that I would consider adding, which is something

you mentioned, because you had said that they can

claim I only have to test to this. And you as

TGRA may say, yeah, but I also want to test to

this. Nowhere does it say. When it says part

543 of this chapter that are testable by the

testing laboratories, so it only refers to what's

in here. If anything, it should say, And any

other requirements by the TGRA to compound upon

that.

MR. PUROHIT: That's part 3 underneath it.

MR. McGHEE: It doesn't do part 3 -- over

here it says that you test for something

different than it says over here. So it doesn't

say in every reference. In all six references,

it isn't stated that I saw. But in here, it

doesn't mention the TGRA part that I know of.

Where she's talking about, it's just the first

one of six. Same references.

MR. WILSON: You're saying that that
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

383

reference (c) is missing from the other places

where that same reference is used?

MR. McGHEE: Well, I mean, he just pointed

it out that it's there. But I don't see that (c)

somewhere else. If I'm looking at it, it may be

further down into somewhere, but --

MR. MORGAN: Daniel, remember, we had this

conversation in the Tribal Gaming Work Group, and

the way we addressed it in the MICS section is we

had that boiler plate language which started

every section which ultimately gave decision

making to the TGRA, whatever the TGRA says.

That's the way we addressed it in the MICS. But

we did not do that in the technical standards.

Because we were worried at least at that

discussion if we try to say it everywhere you

want to, we're going to miss a place. So we're

going to bring it up and make it a catch-all

statement. But we only did it in the MICS. I

don't know if we just didn't think about it in

the techs or not, but that is what happened

there.

MR. McGHEE: Maybe we need a preamble to

the technical standards.

MR. LITTLE: Is there, like, a broader
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

384

concept that could be a recommendation that as we

go through this, the commission does ensure that

throughout the document --

MR. MORGAN: For Class II purposes, I

think that the tribe as the primary regulator

concept needs to be up front somewhere up there

because that's different from your Class III and

you're dealing with the compact with the state

and that's what governs you. In the Class II

world, you get to monitor oversight, very

specific powers set forth in IGRA, the primary

regulator in the hands-on day-to-day stuff is

left to at a local level, the TGRAs. If you want

to put a statement in somewhere, that would be my

suggestion that you put that up there because

that does empower the TGRAs to make sure that

they understand that you do have that authority

and that kind of gives notice to everybody else

that is where that authority lies, at least in my

opinion, properly lies.

MR. PUROHIT: It's in the current preamble

like in the Federal Register, it starts off with

that, and throughout leading into the technical

standards there as well, when you take a look at

the thing. Are you saying maybe put it in 547.1
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

385

or 2?

MR. MORGAN: You have to remember, the

preamble, once you publish it, it goes away. So

you have to go back to the day of publishing the

Federal Register to read that language again.

MR. CULLOO: Maybe it goes in the

definitions section, that statement?

MR. McGHEE: Where we put it in the MICS

is at the beginning of each major section as a

statement that says, for instance, subject to the

approval and oversight of the TGRA, each gaming

operation shall establish, implement and adhere

to internal control policies, and then when you

get into computer applications, the same blanket

statement of the TGRA has that approval, and we

put it at the beginning of each section as a

catch-all. And maybe if we did something similar

that's in the technical standards, we fix it.

MR. PUROHIT: Do you mind pulling up

547.2? It only reads right now that nothing

shall be construed to extend the state

jurisdiction over Class II gaming, or something

along those lines. Matt, is that what you're

thinking or --

MR. FISHER: You mean right here?
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

386

MR. PUROHIT: Yeah. That's not a

preamble. That is actually the section itself in

the beginning of the --

MR. MORGAN: I'm thinking if I can get the

NIGC to say that in a federal regulation, I'm

very happy if they actually make that statement

in writing somewhere that recognizes that.

Because it's bantered about. You do hear that a

lot in the Senate report. You know, just like

we're talking here, when you start talking about

being specific versus why that maximum

technological flexibility. But I didn't actually

look at a part to see where that goes. That

statement currently in 2 is very important

because you want to make sure that, you know, the

Class II is different from Class III, and the

negotiated compact you have with your state don't

interfere with your right to do Class II, unless

you negotiate that away somehow in the contract.

So I don't really know where you want to put it,

but if you're willing to put a statement in

there, I am willing to look to where the proper

place is.

MR. McGHEE: Okay. I vote him go do that.

MR. LITTLE: I would I think it would be
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

387

appropriate for them to put this into a

recommendation.

MR. FISHER: Okay. I started to craft it

the way I heard it. It's now sitting in the --

as a part of 547.2. So how do you want to frame

this and do you want to recommend where to place

it or how do you want to do this?

MR. McGHEE: Could we do like we did where

we ask Nimish, we three came up with here's what

we want you to say and maybe ask --

MR. FISHER: Come back to the group after

lunch.

MR. McGHEE: Yeah, maybe Matthew and

whoever wants to come up with some language.

MR. FISHER: Okay. So actually -- so

who's volunteering to do that?

MR. McGHEE: I think I volunteered.

MR. FISHER: So who wants to work with

Matt on it?

MS. HAMEL: I will.

MR. McGHEE: Only because you brought up

that concern.

MS. HAMEL: I'll do it.

MR. FISHER: By my clock, it's 10:15. We

are scheduled to have a break around 10. Do you
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

388

want to take a break? And if we take a 15-minute

break and start up again at little like after

10:30.

(Recess taken at 10:16 a.m. to 10:37 a.m.)

MR. FISHER: Okay. What's next on the

list? If I go back to this list, you want to

pick up right there? Or were there other things?

MS. HAMEL: No, I think 12 is good.

MR. FISHER: Let me find that in here.

MS. HAMEL: I think generally in 547.12,

without being real specific, that there's many of

the regulations for technical standards are

really procedures, and that either it needs to be

a technical standard that says the system must be

able to do this or the procedure needs to be

moved over or reinforced in the MICS.

MR. FISHER: 547.12.

MR. PUROHIT: Is that like generally the

section as a whole seems to have more of a --

should be kind of like transported away some of

the non-technical standards into the MICS?

MS. HAMEL: Right. And I think yesterday

we just touched on one point that was in the TGWG

document, and changed it to make that comment, to

change that, but there's many references that
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

389

need either to be moved to the MICS or turned

into a technical --

MR. PUROHIT: You're not saying in its

entirety, only the non-technical standards

aspect? For example, what we covered yesterday

in the summary was 547.12(b), the verifying

downloads part. And the consensus, the

recommendation that was adopted is that just

removing -- using any method it seems

appropriate, the TGRA shall confirm the

verification. Does that part remain in the MICS,

but the remaining part stay in there, downloaded

software on a Class II gaming system shall be

verified by the Class II gaming system using a

software signature verification, meeting the

requirements of 547.8?

MS. HAMEL: Shall be verified by, right.

That's what we changed to.

MR. PUROHIT: Right. So language like

that is okay because it's requiring the technical

standards and the design aspects of it.

MS. HAMEL: Yes, and anything that's

procedure, we need to make sure it's addressed in

the MICS. And I believe that's in the server --

the new section used to be called ID and server.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

390

MR. McGHEE: So should we -- Kathi, do you

have the specifics pointed out, or should we make

a general statement recommendation that that

section be looked at to be made less procedural,

is that what we should do?

MS. HAMEL: That's what I think we should

do.

MR. FISHER: How do you want to phrase

that?

MR. McGHEE: That the Section 547.12 be

reviewed by -- to be made less procedural and

more technical, I guess, or made more regulatory

-- or statute. I need a legal guy. I'm looking

at Matthew over there, and he's like --

MR. MORGAN: I agree with your general

thought. Because I think at least what I hear

you say, to put it very simply, technical

standards should be technical, and procedural

should be internal controls. So review it to be

sure that you've pared down the procedurals as

minimal as possible and see if you can make those

procedures transfer over to the MICS.

MR. McGHEE: Or either reword them to be

technical. Because if you put them over into the

MICS, it will affect us later when we try to do
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

391

the MICS and it will be there. I think most of

it could probably be reworded to be -- like we

did yesterday.

MR. PUROHIT: Can I ask Kathi and Mia and

anyone else that had this recommendation, just

like a real quick example, in addition to the one

that we covered, so we kind of get a --

MS. TAHDOOAHNIPPAH: I mentioned yesterday

(a)(6), the Class II gaming system or TGRA shall

log each download of any --

MR. PUROHIT: Like strip the TGRA part

from it? The Class II gaming system is still

going to have that log, right, and that's going

to be something that will be tested at the lab

and designed into the standard. So from like

any -- what would you -- like --

MR. McGHEE: We made a change, did we not?

MR. PUROHIT: To (6)?

MR. McGHEE: We said shall be capable of.

You could probably do the same thing there. Kind

of create a new procedure would be that the TGRA

would --

MS. HAMEL: Number 2 is a procedure.

Downloads of software games, price schedules or

other download packages shall be conducted only
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

392

as authorized by the Tribal Gaming Regulatory

Authority.

MR. MORGAN: Daniel, the wording I have

there, you say "capable." What happens if a

system is not capable? Because I think the

thought process there in the group discussion was

we think it needs to be done, and if this is one

area, if you can't do it automated, then you

manually need to do it in this one instance.

Because it's important that that information get

logged. If you say has to be capable of, you've

taken away that option to manually do that.

You're saying that system has to be able to do

that, and that's a design requirement. That may

be where you want to go. I'm just pointing out

the differences in that.

MS. HAMEL: Maybe that whole section

should be in the MICS, because we've talked about

in the MICS that there are computer applications.

MR. McGHEE: But what you're going to find

in the MICS is a general statement probably that

will say regulations need to be in place that

would allow conducting of -- where's that one

about the -- that would allow the conducting of

logs to be downloaded, whatever. It's going to
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

393

say something like that. It's not going to tell

you the TGRA should do it or who should do it.

That's going to be up to you. So what you want

here just in the technical standards is just that

somehow or another, you should be able to get --

MR. MORGAN: That may be the issue with --

Leo just brought up the system may give you that

information, but it doesn't contain the

functionality to maintain that information, and

that's the manual part that as the information

comes across, you may have to log it. It does do

that, but it doesn't retain that ability stored

somewhere that this is what happens.

MR. FISHER: So I if go back up here,

that's the way I heard the general

recommendation. Let's just see if that captures

it.

MS. HAMEL: So did you want to make a note

in each one that what we think is procedure

versus technical?

MR. FISHER: If that would be useful, yes.

MS. HAMEL: So I would say right there,

(a)(1), downloads, is technical. Do you want to

put it at the end of (1)?

MR. FISHER: Yep. We can do it that way.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

394

MS. HAMEL: Number 2, I believe is -- is

it procedural and it needs to be --

MR. McGHEE: 3 is technical.

MS. HAMEL: 3 is technical. 4 is

procedural.

MR. PUROHIT: 4 is something that can be

tested in a lab environment. It has to stay

behind the scenes. It can't go directly to the

terminal. So from that perspective, I see that

as a technical test as well.

MR. McGHEE: Because it's something you

need the manufacturer to know, not the regulator

to --

MS. HAMEL: For 4?

MR. PUROHIT: Right.

MR. CULLOO: Why would they do a download

without contacting operations. That's up to TGRA

to define how that occurs, that download, when

and where.

MR. MORGAN: But the technical aspect of

it is it cannot download something onto a

terminal. But it's resides there until I say

make it operational. Does it have that

capability to do that. Because they push the

data out there, but it may not change until
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

395

internal control-wise you give proper

authorization that, yes, that now can be played

by the public. And that's a design feature that

they need to have that capability to be able to

push it, but not affect the game play as

currently.

MR. McGHEE: In other words, not be

capable of being --

MR. PUROHIT: The operational period part

makes it procedural, right?

MS. HAMEL: Yeah.

MR. PUROHIT: What I was saying is that

the manner that we want to check the game play,

that's something -- I think this is one of those

gray areas that needs to be cleaned out.

MS. HAMEL: Okay. I think 5 is technical.

6 is procedural, that whole 6.

MR. FISHER: I think I'll put it right

here. That's it.

MS. HAMEL: And then on (b) --

MR. WHEATLEY: Isn't that what we fixed?

MS. HAMEL: We changed it to be capable

of.

MR. FISHER: Yes. And then that's it for

12. All right. So let's go back up here to
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

396

this. Matt and then Daniel and then Leo.

MR. MORGAN: I just had a question on 6.

Procedural, what is your idea to change it?

Because while I do agree that the aspects of it

is procedural, some of those are designed -- at

least I see them as design requirements that

manufacturers need to go -- and hopefully I'm

trying to get to the point, I guess, you're

changing the language there, you're not actually

removing that language; is my understanding

correct?

MR. McGHEE: I think the part of the

sentence is technical. I think where you start

with each log record shall contain, and then all

those things it has to contain is the technical

portion. Because you're saying your system has

to be able to do this. It's just the first

sentence that might be procedural. Is that

your -- do you agree?

MS. HAMEL: Well, what if the system

cannot -- is it a required regulation?

MR. McGHEE: He's saying it's required

that they make sure they do that.

MS. HAMEL: We're saying it's a log, but

if your system doesn't create this log --
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

397

MR. CULLOO: Is this a manual log, is this

an electronic log?

MR. PUROHIT: It's something that's kept

behind the scenes that can be monitored by your

IT staff.

MS. HAMEL: Matt, what you brought up is

real, that it may not stay in the system forever,

that it probably is --

MR. MORGAN: It could get purged at some

point.

MR. FISHER: Do you want to note this one

has both technical and procedural elements to it?

MS. HAMEL: Sure.

MR. FISHER: Let's go back up and look at

the recommendation and see if that captures it in

a way that -- get rid of this. So that's the --

does that capture it for -- I guess let me take

the cards that are up and come back and check

that.

MR. CULLOO: A lot of the questions we're

asking NIGC to do something, so how can we expect

the response to come? Are we going to get to see

something sent to us and look at it and review it

one last time or --

MR. LITTLE: These are recommendations.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

398

Probably not.

MR. CULLOO: What you advise us with the

recommendations that we completed it and it's

available for review?

MR. FISHER: You could make the

recommendation -- instead of recommending that

they review it, you could recommend that they do

it, right? So instead of saying review by NIGC

to be more technical, it's that you would

recommend that this provision be changed to be

technical rather than procedural, and that you

move the procedural things so you've -- it's what

you have up there, but it's a direction rather

than a request for a review, is what I'm trying

to say.

MR. McGHEE: Maybe it would be more

beneficial, if your concern is what will it end

up looking like, is to actually either we fix it

now or a subgroup get together and makes a

suggestion and brings it back to the table for us

to agree on.

MR. LITTLE: That's probably a better

method.

MR. FISHER: Okay.

MS. HAMEL: I'll help however I can.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

399

MR. FISHER: So wait. Now we got multiple

things going, so now I got to track it. Who's

going to -- so I can track who's going to bring

back what to the group, so who's going to work on

this? Mia and Kathi.

MS. HAMEL: Matt, do you want to help?

MR. MORGAN: I'll help, yeah.

MR. FISHER: Then you can do 547.2 at the

same time.

MS. HAMEL: Leo, too.

MR. FISHER: I'm going take this one out

because I'm tracking this by what ends up with

the recommendation in yellow so I can come back

to that if that's the way you decide to proceed.

Okay. Anything else on 547.12 before we move to

the next one?

MR. McGHEE: How are they going to bring

it back? Because he's already working at lunch

on something else.

MR. FISHER: I thought maybe they could

work on both of them.

MR. McGHEE: Okay. I could be added to

the group and then --

MR. MORGAN: You got drafted.

MR. FISHER: So in response to Daniel's
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

400

question, when will you bring this back to the

group?

MR. MORGAN: When we are finished.

(Laughter.)

MR. McGHEE: We hope to be done after

lunch.

MR. FISHER: When should the group check

with you on how you're doing?

MR. MORGAN: We should probably have

something after lunch to report back. I would

guess after lunch. We thought we got a good shot

at it. Or if not, it may take a little longer,

and we may need tonight.

MR. FISHER: That's good, because we are

working on the goal of completing the technical

standards today.

MR. MORGAN: We will work hard to finish

this at lunch.

MR. FISHER: Thanks.

MR. LITTLE: I think Nimish has some free

time over lunch.

MR. FISHER: You're volunteering technical

assistance?

MR. LITTLE: On the second group, not the

first one.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

401

MR. McGHEE: You can sit at a table next

to us.

MR. PUROHIT: I'll go in a corner in the

time-out mode when you discuss the first one.

MR. FISHER: All right. So if I flip back

here, 547.14(f). And let's see, trying to go

there, to (f).

MR. WHEATLEY: I thought we finished that

yesterday.

MS. TAHDOOAHNIPPAH: Did we finish the

summary document, is that what we're on?

MR. FISHER: It was something on my list

as to whether --

MR. WHEATLEY: It was the algorithm.

MS. HAMEL: I thought we finished that.

MR. FISHER: So much for my list. We

actually did. So here's what I have on my list.

We did (f)(4), but what I have on my list was

(f)(1), this part. Is there anything we need to

do with that, or is that okay?

MR. McGHEE: I don't know where that came

from.

MR. FISHER: Okay. All right. So --

MR. PUROHIT: I think that was the fact

that there was an example in there. That was
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

402

Kathi's question, that that's the first time that

there was an example.

MR. CULLOO: But there's not an example.

MR. WHEATLEY: There's not an example.

MR. McGHEE: It was be independent and

uniform over the range.

MR. PUROHIT: That's the only thing I

remember from yesterday that I don't know if we

resolved or not.

MR. FISHER: Okay. So then that was

everything, Kathi, that you raised yesterday and

that Mia raised. So, Tom, you said you had

something else you wanted to raise?

MR. WILSON: Yeah, I just -- it's not a

concern. I want to understand the definitions,

the term "agent" is used. And, you know, that

has a lot of different meanings, different

places, so I'm just -- I'd like to understand

first before I decide if I've got an issue or not

as to the rationale for using that particular

term as generic to anybody who's an employee.

Basically it sounds like anybody who is assigned

some functionality dealing with this is

considered an agent for purposes of doing

something.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

403

MR. McGHEE: I think we used it anywhere

an employee was.

MR. MORGAN: Not necessarily. It was --

it was meant as a catch-all phrase, one. And try

not to unnecessarily force you to do something

that is within your operation you wouldn't

normally do. So we tried to not say a particular

employee. We tried not to say a particular

department. Our point was that somebody has to

be authorized to do that. They can't do it if

they're not authorized. Whoever that authorizing

entity may be depending on what your subject is.

You have to be authorized, one, and at least when

we get into -- especially on behalf of the MICS

side of it. Two, it was very important that

whoever is performing the action is not the same

group that's verifying that that took place; that

that independence is established. But we got

into large discussion because, you know, for

example -- and it really bleeds over to the MICS,

and I apologize -- is that when you get into

bingo, when you say this department shall check

this, what if you don't have that department? Or

what if within function, what if your internal

auditors are actually contracted out and they're
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

404

not internal; you can't say the internal audit.

It would just be whoever is that agent. So it is

meant to use as a catch-all, and it can be

various meanings depending on what section --

MR. McGHEE: It can also be computer

applications, according to -- the definitions

said this definition permits the use of computer

applications to perform a function of an agent.

MR. MORGAN: If that function was

automated and that has become, in fact, your

agent, because we had several groups that

participated that said basically we've automated

all this function, and the only reason that we

actually produced this paperwork and have that is

because your requirements tell us we have to. So

it's an audit function. From an efficiency

standpoint, we don't need it anymore. We have an

automated person or functionality that does that.

But for what you tell me I have to do, I have to

pay something to follow up on that now. And,

again, trying to be flexible.

MR. McGHEE: We didn't want to use a

person because of the computer program. It could

be something else. So that's why.

MR. MORGAN: For me, at least, in those
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

405

conversations an important part was an agent has

to be authorized. If you're not authorized, you

know, you cannot do that. And that is that

lynchpin that really gets you there. Somebody

has to authorize you. And of course the people

that authorize you have to be in that position in

order to do that. But it is a catch-all phrase

that was meant to broaden the fatal options to

your -- at a local level and say how do you get

this done. And, again, it may have more

applicability on MICS than on the technical

standards, but there are places in both documents

where that -- and we tried to make that, I think,

be consistent since we used that term in both

documents. We tried to make it as consistent as

possible. It may be a very poor job explaining.

MR. WILSON: No, it makes sense now. I

just had never seen that term used in the way

that you're using it, so I wanted to understand.

MR. LITTLE: We had a lot of questions

regarding -- not a lot of questions. We did have

some -- we did wonder what was meant by that.

Could an agent include a non-employee, which

may --

MR. CULLOO: Contractor.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

406

MR. LITTLE: Yeah.

MS. TAHDOOAHNIPPAH: Throughout the

document there is the word "employee" used, so it

isn't consistent. And then so it never defines

an employee, but it does refer them in several

parts of 547 --

MR. PUROHIT: 547.7(g). That's the one

that we talked about.

MS. TAHDOOAHNIPPAH: (g). There it just

uses the word "agent," but then on (f), it says a

gaming operation employee or agent. And then --

MR. MORGAN: To be quite honest with you,

that was probably a discussion that, as Dan said,

his concern is who can it be. It could be an

employee, but we probably had somebody making an

argument that I want employee to stay, and you

had another part of the group saying that, yeah,

but we could task that out somewhere else. So

the compromise of the group was, fine, we'll use

employee or agent there.

MR. WILSON: Is the presumption, though,

that an authorized person -- where it says that,

you know, as approved by the TGRA. Approval in

my mind means that that's somebody that needs to

be licensed.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

407

MR. McGHEE: Not necessarily. A list

provided, which means people that can do this

function and you agree as a TGRA that, yes, that

his position or title of those people are --

should be authorized instead of putting every

employee on the list.

MR. MORGAN: It may depend on what you

deem to be licensable at your place. If you deem

this group to be licensable, they may need to be

licensed. But if you deem another group who

maybe performs a function that is non-licensable,

that doesn't necessarily trigger it has to be

licensed. That is your choice on almost whether

that trigger is a licensing and the issuance of

that.

MR. FISHER: Mia and then Nimish.

MS. TAHDOOAHNIPPAH: I would just suggest

that the definition somewhere include an

employee, and if not, then take out the word

"employee" throughout the document and just use

"agent."

MS. HAMEL: Can you search for employee?

MR. FISHER: Yes.

MR. PUROHIT: Go to 547.7(f). That has

employee and agent listed there.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

408

MR. McGHEE: I'm curious how many places

it's used. It might give us an idea as to why it

was --

MR. WILSON: Looks like the original

definition of agent included that it meant an

employee or somebody else, and then that was

struck out.

MR. FISHER: You want to go, Nimish, to

547 --

MR. PUROHIT: 7(f).

MR. FISHER: Take me a second to get down

there. There you go.

MR. PUROHIT: That's got an employee or

agent as Mia was saying. My concern is when you

include computer applications in general or

software in general, does that kind of like

conflict with this definition? I mean, the

storage component requirements and the financial

instrument. Because in essence you're saying

it's not designed to be operated under the direct

control of a software, but then there's all these

other requirements over there as well, if you

really liberally include that software as well.

MR. FISHER: In the definition of agent,

you mean?
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

409

MR. PUROHIT: Correct. Food for thought

for the TAC, again, if you do include that. So

in essence, like a financial instrument device is

now under the control of an agent, software, that

doesn't have to be locked up, according to this,

if you read it loosely.

MS. HAMEL: I read it as not --

MR. PUROHIT: To include software, I think

there might be unintended consequences in here as

well, and I would recommend that that part might

need to be cleaned up a little bit.

MR. McGHEE: You're saying that you -- any

Class II gaming system components that store

financial instruments that are not designed to be

operated under the direct control of a gaming

computer application shall be located within a

secure area, you're saying that's a problem?

MR. PUROHIT: I'm looking at the converse

of that.

MR. McGHEE: You're saying if agent were

to be transposed with computer application, which

it could be.

MR. PUROHIT: Right. The way I read it is

if something is under the control of an agent, it

doesn't meet the requirements of an agent. If
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

410

the agent is a software, then there's kind of a

little bit of conflict over there. To say on the

one hand if it is not under the control of a

person, then it can't be; it's not been designed

that way. So then it's immune from all the

testing requirements. But in this particular

case, that it's saying it's not only a person,

but it's also an agent, which includes software.

I'm seeing it from a testing and design issue

over here. Because it says the definition

permits -- agent definition it says, permits the

use of computer applications. So, you know, just

a real loose interpretation can say, well, the

firmware that controls the bill accepter or the

financial instrument accepter in this case is an

agent. Something I'm throwing out there.

MR. MORGAN: I understand what you're

saying there. And, again, sometimes it comes

from trying to make this fit into an electronic

game and a session bingo, some of those

difficulties that arise there. Because one of

the reasons we put that in there is if you're

playing session bingo and you have a cash drawer,

you don't necessarily need a lock on there if

that cash drawer is going to be manned because
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

411

why are you going to put a lock on there if

you're at bingo and you're paying out cash after

each game; that doesn't make sense. That's an

internal control, is how you're going to mitigate

the risk there. But I grasp what you're saying

there. Because we tried to make agent as broad

as we could to make sure it fit every situation.

We made it overly broad in this one context.

MR. FISHER: So, Tom, you still have your

card up.

MR. WILSON: Well, I was just reading the

definition of financial instrument. And so if

you're reading the definition of financial

instrument, it's really talking about a tangible

thing that is being stored somewhere. So I don't

know if a -- in your interpretation, the agent

could be a POS system that is storing -- an

automated cash drawer, let's say, or, I mean, I'm

trying to get to where you're coming from. The

implication is that a piece of software or a

piece of hardware that is not manned by a human

being based on that could be -- not have to be

otherwise secured.

MR. PUROHIT: Actually this fits the POS

system in session bingo. What this doesn't now
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

412

fit into, in my opinion, is a gaming terminal

that has a locked compartment, an automated

financial instrument accepter, such as the bill

accepter that they're saying in there as well,

which is controlled by the software, the firmware

that's inside the gaming terminal that acts as

accepting valid currency, financial instruments,

et cetera. So now that software, the definition

of agent says, it's also software applications

that act as that. Does that mean that now

because it's being controlled by a software

acting as an agent, it's exempt from the

requirements of a financial instrument except for

testing?

MR. WILSON: Okay.

MR. PUROHIT: See what I mean? If you

take a really liberal, loose interpretation of

it.

MR. McGHEE: Well, it's not saying you

have to test. It's just saying that it has to be

located within a secure, locked area, right?

That's not talking about testing, is it?

MR. PUROHIT: I think it's F, G and H.

There's other requirements in there, too.

MS. TAHDOOAHNIPPAH: I just -- why
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

413

interpret it that way? I think that I interpret

it the way you do, Daniel, that if it has a lock

on it, then, you know, that's designed to be.

But if it doesn't have a lock on it, like, you

know, a money pouch, that it's under direct

control of an agent.

MR. PUROHIT: (g)(ii), for example, has

that same language; any Class II gaming system

component that handles financial instrument and

that are not designed to be operated under the

direct control of an agent shall, and then it

says (ii), be able to detect the entry of valid

or invalid financial instruments and provide a

method to enable the Class II gaming system to

interpret and act on valid and invalid input or

error condition. That right there is a testable

technical standard, and that's the conflict I

see. Someone could say if it's not under direct

control of an agent, then it has to meet the

requirements in this particular case. So is it

or is it not under the controlled software, which

also acts as an agent? Something to consider.

Maybe it needs to tighten up the definition of

the application and the software, whatever else

it is.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

414

MR. MORGAN: I would worry about

tightening up the definition. I would suggest if

there's specific areas within the technical

standards where that confusion exists, you may

want to take care of it there. Because to make a

global change in the definition, you have

unintended consequences when that term is used

that we may not be recognizing at this point.

And I do agree with you, there may be some

instances in here where it doesn't quite make

sense. And like that language right there, I see

that word "direct" pop out at me. So clearly

that has some significance. But interpretation,

what does that significance hold to you, I'm not

for sure. But clearly use that under the direct

control of an agent as a -- somehow to

differentiate between indirect control, so does a

computer application have direct control or is

that term indirect control or something less than

direct? I'm a lawyer, and words take on

significance. The engineering part of it, I'm

not for sure. But that clearly jumps out at me

from a legal standing of direct control. And

Mia's example when you look back at a -- it says

employee or an agent --
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

415

MR. McGHEE: I think that was a mistake

because everywhere else it doesn't say employee,

but it uses the same language. I think it was a

miss.

MR. MORGAN: I think that was miss there.

If a person is performing that function, you

shouldn't have a lock on it. But if a computer

application is doing it, you probably do need it

monitored somehow.

MR. FISHER: Jeff has his card up. Let's

take him and figure out what we want to do with

this.

MR. WHEATLEY: I was going to agree with

Nimish, it does sound if it is under the

operation of an agent, and the agent is software

or bill validator or firmware, then the drop box

doesn't have to be locked, which is what that

implies. I think somebody could make that

reference if it's not cleaned up somehow.

MR. FISHER: We started this with what's

the definition of agent. Then we went to use of

the word "employee" and "agent," and then focused

on a couple of specific provisions that used the

word "agent" and how the revised definition might

affect those provisions. So what do you want to
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

416

do now? Do you want to go back to the definition

of agent, or do you want to take a look at this

off line and come back to the group?

MR. McGHEE: Could you, just for this

technical section, actually do the search and

find to see where "agent" is used? Maybe it's

only used in a couple places and it can be fixed.

I don't know how often that it's used.

MR. MORGAN: Did you find agent or

employee?

MR. FISHER: Do you want me to search

agent or --

MR. McGHEE: Agent. Because employee is

really not supposed to be in there.

MR. MORGAN: I think employee should be in

there on some parts. It's a difference between

whether it's a computer application is doing it

or whether it's completely manual. Because the

inverse is happening and one of the reasons that

we tried to make agent broad is people were

trying to meet something. I did it all manually,

but you're telling me, you know, it has to have a

lock on it; now I'm locking my cash drawer or

something.

MR. McGHEE: Do you think wherever you
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

417

find agent, you're going to see employee or

agent? Let's do one at a time. Let's go to

agent and see what we can.

MR. FISHER: So it says there's only two,

but that's actually not correct.

MR. MORGAN: If you remember, we had lots

of this conversation in the MICS. This

conversation probably didn't flow over into the

technical standards as that significant at the

time. It may be something we just overlooked in

the technical standards and we didn't think

about.

MR. WILSON: It seems that even -- I mean,

in my mind, based on what everybody is saying,

the issue isn't where the term "agent" appears or

the term "employee." It's the definition of

agent including computer applications, that it's

including computer applications. And therefore

wherever a computer application is used, it is

treated the same as a human being standing there

and not having to meet the same control standard

because a person really isn't standing there or

in control of it. It's a piece of hardware or

software that is existing. It's almost like

we're giving human characteristics to an
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

418

application, when we're really talking about

physical security. And to the extent that an

application addresses physical security, then

that's appropriate. But if the application is

supposed to think about something, then, you

know, I mean, that's where I see the thing coming

in to what Nimish is saying. So I don't see it

as an issue using the term "agent" or using the

term "employee." I see it as that piece in the

definition of agent that says a computer

application can perform the role of a person,

essentially, and therefore this standard doesn't

apply when you have that person standing there in

physical control of this box, let's say, this

cash box or whatever it happens to be.

MR. FISHER: Did you want to respond to

Tom?

MR. McGHEE: Yeah. Because there's

instances where it could -- you know, like say

over in drop account, where once upon a time

people had to think that three people had to

count it individually, and then when you got this

big counter, it counted it three times for you

and that was able to be substituted because it

was a computer application instead of agent,
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

419

meaning a human. So maybe it should really be

either something along the lines of where the

computer application is applicable or whereas a

TGRA, you decide that agent could be a computer

application. You make that assumption. But it

could be one spot. Because if we take it out,

then we're going to have to look through the

whole document to see wherever agent is used

throughout the whole thing. Because there might

have been times when it was being done when we

allowed agent to be both, and it could be both.

MR. WILSON: I guess in my mind, when you

talk about controls, there are automated controls

and there are manual controls. So the use of a

computer or an application or software, whatever,

is typically an automated control. And that's

perfectly recognized that it's okay to have an

automated control that takes the place of what a

human used to do. And that's really what the

intent here is what you're saying is that you

want to allow for automated controls to exist

that do not have to -- or that it's already

accepted that they perform the same function as a

person did. So, you know, in my mind, this is

more of a MICS issue than a technical standard.
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

420

MR. MORGAN: That's kind of where I was

going, because the Tribal Gaming Work Group kind

of made a policy decision to do it. If we

defined this term in one document, we used the

same definition in both documents. That was a

policy decision to keep them consistent. Because

some of these ideas do overflow into different

documents. That may be a decision that this

group wants to reevaluate and say the definition

for agent in the technical standards may need to

be different from what it is in the MICS. I

agree with you on that. My other point is,

Nimish, because you're very intelligent in this

area, is this a practical real world issue or is

this a law school theory-based

this-could-possibly-happen?

MR. PUROHIT: Both. Because if you were a

manufacturer --

MR. MORGAN: Not if. How many times have

we heard about this coming up that this is an

issue?

MR. PUROHIT: Not until now because there

was no definition of agent to include this. But,

you know, from a testing perspective, the

manufacturer could come into an independent test
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

421

lab and -- I'll give you an example of other

ambiguous regulations. If something uses the

word advertised top award -- I'm giving you

something unrelated here -- but this is an

example of something that's so ambiguous, that

the manufacturer says we meet this requirement.

But, you know, at the end of the day, it's still

their responsibility to go to the TGRA and figure

out what that is. But what I'm trying to

highlight here is why make it ambiguous if it is

only causing that ambiguity and we know about it,

as opposed to leaving it in there that can be

resolved by just sharpening up the definition a

little bit more that needs to.

MR. MORGAN: I don't disagree with that.

I was just trying to get a sense of risk/benefit

analysis. Are we talking about a subject that

has some real applications that we need to spend

-- what amount of time and effort does this need,

or is this a theoretical argument that somebody

could read it that way, but we don't see it this

way, but this ambiguity does exist and as long as

everybody knows it out there. It's a policy

question, what the group wants to do. But I do

agree with Tom's point that the -- how we use the
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

422

term "agent" in the technical standards is

probably different than how we use the term

"agent" in the internal controls document, which

may necessitate a change to the definitions in

that term.

But going back to Daniel's point, when you

start changing that definition, it does have

global implications and changes, and we really

need to go back and see how it changes each

instance it was used within the document.

Otherwise you may be making another unintended

consequence and create ambiguity someplace where

ambiguity was not before.

MR. FISHER: According to the thing up on

the screen, the word "agent" is used eight times

in the technical standards.

MR. McGHEE: I think we could just look at

them.

MR. FISHER: Do you want to look at them

or do you want to --

MR. WILSON: I think if it's eight, we

could look at them and see if contextually it's

confusing or it's misleading or can be construed

as --

MR. FISHER: There's two of the eight
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

423

right there.

MR. CULLOO: You have to search

"employee," too, in there.

MR. PUROHIT: Also, Matt, the reason

why -- the theoretical part of it here. Any time

there's software introduced in the technical

standards, you got to realize from your

experience, too, the minute that's introduced,

the independent test labs have to comb through

and figure out which other tests that they need

to put in there. From that perspective, the

technical need to be updated for all the other

sections that might not have had the consequences

before from a testing perspective or software.

MR. MORGAN: My question on policy level

is more -- we've had this discussion several

times -- at what level do you hit on the

regulation, because the more specific you get and

less ambiguity you have, while in some instances

is a positive for you, you know, on the flip side

of that, there's also some negative things that

come along that you have to accept when you make

that choice when some of your interpretation goes

away. Sometimes it's good, sometimes it's bad.

And if you do it at a global level, you're just
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

424

accepting if we don't go back and look. I'm glad

there's only eight.

MR. FISHER: Really there's only six

because two of them are in the definitions. The

first one is where Nimish pointed us to. The

next one is in the same -- it's in the next

section. So it's in -- just following it, same

section we talked about.

MS. HAMEL: Can we just say in those

instances where we don't want an application to

meet the requirement of an agent, can we say with

the exception of -- just in those two sections,

right?

MR. MORGAN: My thought, too, is kind of

the same way, maybe a different way to get to it.

You just take out the word "or agent" in those

areas because it would be clear that a person is

not subject to that requirement. But from a

physical standpoint, a computer application may

still have to meet that. Because I agree with

you, read it the way Nimish has read it. But

there's confusion maybe if you're a computer

application, suddenly you're exempt from that

standard. Maybe a very small inconsequential

concern, direct control of a gaming operation
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

425

employee. One of the reasons we used agent is we

wanted to be broader than saying it has to be an

employee. And why we included a computer

application with a person or individual, I mean,

do you want to make it so narrow that it says

gaming operation, or do you want to make it -- is

this defined as a human being, person,

individual. Is that --

MR. WILSON: Well, I guess from my

perspective, that's the issue is that it's not

that either piece is right or wrong. It's that

what we're trying to apply characteristics to a

computer application when our intent is talking

about really -- I mean, I can envision the

discussion is about I don't have to have my pouch

secured, you know, it's on me. I'm performing

that role, versus a box that is sitting here that

I need to make sure is locked and secured. So,

you know, in trying to envision a computer

application so the bill accepter or something has

to have certain control components within his

that need to be there from a manufacturing

standpoint. So, to me, it's more almost like

we're trying to imply physical security

attributes to the whole computer thing. And I
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

426

think I know where you're all going with the

computer thing. I'm just not sure if the way it

was approached in that definition, it gets --

makes it more confusing.

MR. McGHEE: Can we just say, like you

mentioned earlier, it says gaming operation

agent. I think you say other than computer

application agents. You know, it kind of takes

that portion of it out. Meaning all of the parts

of the definition of an agent other than a

computer application.

MS. HAMEL: Well, maybe we're

over-thinking it. Would we ever test a pouch,

and why are we putting that disclaimer out? We

want to test, but if we take it out, if we take

out "that affect" -- if we stop at "affect the

game outcome," and take out "and then are not

designed," because that would never get submitted

to the lab anyway to know that it needed to be

tested, right? I mean, it's a physical --

MR. PUROHIT: The "not designed" part was

put in for session bingo.

MS. HAMEL: But that isn't --

MR. PUROHIT: That's what my understanding

is. The words --
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

427

MS. HAMEL: I understand that, but maybe

because this is something that's physically

tested, it's a technical standard, maybe it's not

necessary at all. We probably need somebody

technical to talk about it.

MR. FISHER: I just have to point out that

we're at 11:30. According to our agenda, 11:30

is the time for public comment. So we need to

pause here a moment and check whether we have

anybody for public comment. I don't believe

anybody is signed up on the sign-in sheet for

public comment. So if there's anybody in the

audience that wants to give public comment at

this time, now would be appropriate to let us

know. So there is nobody who wants to make

public comment so we're able to keep moving on on

the discussion of technical standards.

So on this question about the definition

of agent and the use of the term agent and the

use of the term employee, do you want to keep at

it here, or do you want to ask some kind of

smaller group to look into this and come back to

the group with a suggestion for how to handle

this? What's your preference?

MS. TAHDOOAHNIPPAH: I suggest we go into
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

428

a closed session and discuss it.

MR. FISHER: Is that what you want to do?

Yes. Okay. We will do that and then we will

just go to lunch.

(Executive session - discussion held off

the record.)

(Recess taken at 11:32 a.m. to 1:44 p.m.)