Subject: [Rats] looking for better terms -- request for bike shed discussion

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jan 2020 11:04:11 -0500

None of us have been happy with the confusion due to the alliterative
terms "Attesting Environment"(1) and "Attested Environment"(2)

We agree that (1) *measures* (2).

We think that we could keep one of the terms (1) or (2) if we could come with
a different enough term for the other.  There is an issue open:
  https://github.com/ietf-rats-wg/architecture/issues/14

I asked Google, "What is a person who measures", and the answer it gave me
was "surveyor".  There was criticism of this term because it sounds too
active. (To "survey" in the civil engineering sense is quite active)

What do you think?

https://www.thesaurus.com/browse/surveyor?s=t

assessor
cartographer
measurer
land surveyor
mapmaker
topographer

https://www.thesaurus.com/browse/survey?s=t

includes a bunch of interesting words, some of which we use already:

assess
canvass
check
check out
estimate
evaluate
examine
inspect
look over
observe
overlook
oversee
review
scan
supervise
appraise
assay
case
contemplate
measure
plan
plot
prospect
rate
read
reconnoiter
research
scope
size
study
summarize
superintend
valuate
value
view
check over
check up
give the once over
look upon
set at
size up
stake out
test the waters

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Jan 2020 16:12:24 +0000

These terms aren't great, but they seem to be widely used in industry.

Adding as new "better" term will not help.  Please don't.

If you need nouns to indicate the entities operating as (1) or (2), then perhaps attestor and verifier.

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 Jan 2020 08:37:28 -0800

How about (1) “attester" and (2) “target" or “subject”? 

Currently the EAT draft roughly uses “entity” and “submodule” for (2), but only roughly because it doesn’t distinguish between (1) and (2).

Attestation is not certification, but somewhat similarly Common Criteria certification uses “target of evaluation”.

LL

> On Jan 7, 2020, at 8:04 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 7 Jan 2020 16:54:33 +0000

Attesterr and target have also been my first thought...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 7 Jan 2020 21:43:40 +0000

It may be helpful to note that the Attester may not be the same as the environment that measures. In some cases it is the same but not in all cases. The Attester contains both (1) and (2) so it seems we don't want to overload (1) or (2) with a term that is the superset of both. 

If there is consensus terminology for either (1) or (2) then we only need to change one of them. 

The analogy to CC seems somewhat apropos as attestation could be described as the partial automation of a (manual) certification process. Indeed, the result of CC evaluation could be a claim in a manifest or certificate issued by an Endorser. The Verifier likely would expect to find an overlap between the ToE and the "Attested Environment".

-Ned

On 1/7/20, 8:54 AM, "RATS on behalf of Schönwälder, Jürgen" <[email-masked] on behalf of [email-masked]> wrote:

    /js

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 Jan 2020 18:17:25 -0800

Here’s some rough text:

Conceptually, the “attester” produces a set of “claims” about a “target”. The claims are known as “attestation evidence” and are sent to the “verifier”. The verifier additionally takes in “endorsements”, processes the attestation evidence and produces the “attestation result” for the final consumer, the “relying party”.

This description left conceptual for easy understanding and discussion. Actual implementations are usually more complex in at least one or more of these ways:

* The attester is also the target
* One attester produces claims about several targets (submodules)
* The verifier and the relying party are the same
* Claims may be simple or complex, many or few
* Some claims are measurements and some are not
* Some claims in in the attestation evidence may be simply passed through the verifier, others may be heavily processed.
* Daisy chaining  -- the evidence from one attester goes through a verifier producing results which are taken as claims that are input to another attester that outputs a different set of evidence that goes on through a different verifier.
* Daisy chaining may happen on the device producing the attestations or in the infrastructure evaluating the device or both.

(Next I’d write a plethoras of simple examples for attester, target, claims… assuming only the simplest implementation that maps to the conceptual description )

I am starting to prefer the basic conceptual / abstract description over one that is inherently mappable to every possible.

LL

> On Jan 7, 2020, at 1:43 PM, Smith, Ned <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jan 2020 14:34:54 -0500

Thank you for this very nice text. I rather like it.

    > Conceptually, the “attester” produces a set of “claims” about a “target”.
    > The claims are known as “attestation evidence” and are sent to the
    > “verifier”. The verifier additionally takes in “endorsements”, processes
    > the attestation evidence and produces the “attestation result” for the
    > final consumer, the “relying party”.

    > This description left conceptual for easy understanding and discussion.
    > Actual implementations are usually more complex in at least one or more
    > of these ways:

    > * Some claims in in the attestation evidence may be simply passed
    > through the verifier, others may be heavily processed.
    > * Daisy chaining -- the evidence from one attester goes through a
    > verifier producing results which are taken as claims that are input
    > to another attester that outputs a different set of evidence that
    > goes on through a different verifier.
    > * Daisy chaining may happen on the device producing the attestations
    > or in the infrastructure evaluating the device or both.

    > (Next I’d write a plethoras of simple examples for attester, target,
    > claims… assuming only the simplest implementation that maps to the
    > conceptual description )

    > I am starting to prefer the basic conceptual / abstract description over one
    > that is inherently mappable to every possible.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 9 Jan 2020 00:02:41 +0000

I don't think I have any problems with Laurence's terminology but just to test it...

We have devices running Trusted Apps on OP-TEE over trusted firmware on an ARM TrustZone processor.
The full evidence is a DICE cert chain that has a set of claims for each cert in the chain, where each layer is an attesting environment for the subsequent layer (attested environment):
	Hardware -> Trusted Firmware -> OP-TEE -> TA
Thus there are four claim sets in a chain.

Using Laurence's terminology, I believe the suggestion is that attesting environment is an "attester" and an attested environment is a "target".   Thus the example above has 3 attesters (Hardware, TFW, and OP-TEE), and 4 targets (HW where target == attester, TFW, OP-TEE, and TA).

Are you ok with saying that every claimset in a chain is from a separate "attester"?   I believe this is different from our current definition of Attester (which is the thing that sends the whole chain to a verifier), so want to confirm.

Dave

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, January 8, 2020 11:35 AM
To: Laurence Lundblade <[email-masked]>
Cc: =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?= <[email-masked]>; Smith, Ned <[email-masked]>; [email-masked]
Subject: Re: [Rats] looking for better terms -- request for bike shed discussion

_______________________________________________
RATS mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40microsoft.com%7Cb7301d9b535a436003db08d79471dc41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141089066538773&amp;sdata=fynNh%2FKEJgaGj1fQNwQYBjdgxQE5XUFl%2BeyA0nOkpJs%3D&amp;reserved=0

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 9 Jan 2020 01:10:14 +0100

Hm...

on one hand, this seems to imply that the "attester role" in this chain 
does not reside on the same "entity" (in other words, multiple entities 
are composing the chain with their individual attester roles). If that 
is what you were trying to state, I am uncertain what problem this would 
address.

On the other hand, maybe there is a use case for this? Alas, I am under 
the impression that this route could imply a tremendous increase of 
architectural complexity.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 9 Jan 2020 00:18:26 +0000

If you're asking about my example, there's only one device, this is standard DICE cert chain functionality on a single ARM processor.

Dave

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Wednesday, January 8, 2020 4:10 PM
To: Dave Thaler <[email-masked]>; Michael Richardson <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: Smith, Ned <[email-masked]>; Schönwälder, Jürgen <[email-masked]>; [email-masked]
Subject: Re: [Rats] looking for better terms -- request for bike shed discussion

Hm...

on one hand, this seems to imply that the "attester role" in this chain does not reside on the same "entity" (in other words, multiple entities are composing the chain with their individual attester roles). If that is what you were trying to state, I am uncertain what problem this would address.

On the other hand, maybe there is a use case for this? Alas, I am under the impression that this route could imply a tremendous increase of architectural complexity.

On 09.01.20 01:02, Dave Thaler wrote:
> 	Hardware -> Trusted Firmware -> OP-TEE -> TA Thus there are four 
> claim sets in a chain.
> 
> Cc: =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?= 
> <[email-masked]>; Smith, Ned 
> <[email-masked]>; [email-masked]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40micr
> osoft.com%7C1afca74f029a4dadf1c408d794985931%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637141254420421263&amp;sdata=WexYiuPGPh%2FSoz2tagX
> wf3Pe3CScQeOgM%2Bd5zPQdeyY%3D&amp;reserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40micr
> osoft.com%7C1afca74f029a4dadf1c408d794985931%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637141254420421263&amp;sdata=WexYiuPGPh%2FSoz2tagX
> wf3Pe3CScQeOgM%2Bd5zPQdeyY%3D&amp;reserved=0
>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 9 Jan 2020 01:26:21 +0100

> Are you ok with saying that every claimset in a chain is from a separate "attester"?   I believe this is different from our current definition of Attester (which is the thing that sends the whole c…

This would imply multiple entities (in contrast to "there's only one 
device") and I was not sure how to interpret that correctly.

I am in agreement that it should be one device (which boils down to one 
entity in the rats arch at the moment).

My assumption is that this is just a wording issue and we actually mean 
the same thing :) I only wanted to be sure, because multiple attester 
roles creating a single chain would require a significant overhead of 
'attestation provisioning procedures' which will be in scope for the 
first rechartering, but not right now.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 9 Jan 2020 01:49:40 +0100

Oh! I just realized...

you are referring to the initial topic of layered attestation where 
there is a sequence of attested environments becoming the attesting 
environment and so forth. If so, I misunderstood your initial statement, 
I think.

The "separate attesters" you were referring to are the staged 
environments that become attesting environments during boot in a single 
entity, yes?

If so, we are in wild agreement and it just took me while to get it...

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 9 Jan 2020 01:34:26 +0000

Equating the "attester" with an "attesting environment" may be fallacious. For example, the TA might be the thing that signs the conveyance protocol frames and delivers the cert chain to the Verifier. However, it (the TA) isn't an "attesting environment" it only ever is a "target environment". 

The Verifier MUST(?) detect the DICE layering convention and walk the graph back to the original (root) "attesting environment". Even with DICE layering, there is still only a single "device" (endpoint) that the RATS Role will call "Attester" and it consists of multiple "attesting environments" and multiple "target environments" where some of these are both an "attesting" and a "target" environment during its lifetime. 

It may be incorrect to say that the TA is the RATS "Attester" because the Attester is supposed to be a pledge that can prove it is a trustworthy endpoint to the Verifer. The endpoint isn't just the TA, it is the chain of things that anchors it to the first "attesting environment". 

The root/anchor "attesting" environment relies on its mfg to establish trust using a mfg issued certificate that vouches for the process that manufactured it and likely issues an identity credential (IDevID). The IDevID allows the Verifier to disambiguate which of possibly multiple instances of Attesters it is talking to currently. 

It seems reasonable that an EAT submod structure can be used to represent DICE layering (so could an X.509 certificate chain). However, a submod could also describe other relationships / decompositions of a multi-component endpoint. For example, if the OP-TEE consisted of multiple chips then there could be multiple vendors, part numbers etc.. and therefore multiple submods where all of them (likely) are "target environments".  

DICE layering comprehends hierarchies too. If one of the OPTEE sub components had DICE capabilities it could become an "attesting environment" to one of the OPTEE chips (branches). But this more complex thing is still dependent on its path to the anchor/root "attesting environment" so it can't (in isolation) claim to be the "attester". 

If the TEE was an SGX instead of an OPTEE, then the anchor "attesting environment" is SGX uCode rather than HW --> Trusted FW. The SGX "attesting" and "target" environments are orthogonal to the non-SGX "attesting" and "target" environments, but nevertheless part of an IA "device". It is possible therefore to have multiple "Attesters" in the same SGX-capable "device".

-Ned

On 1/8/20, 4:02 PM, "Dave Thaler" <[email-masked]> wrote:

    

    Dave

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 9 Jan 2020 01:36:11 +0000

Please see my other post that crossed in mail. I don't think the convention holds for DICE layering that DICE layers are "Attesters". 

On 1/8/20, 4:50 PM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Oh! I just realized...

    
    
    Viele Grüße,
    
    Henk

---

From: Dave Thaler <[email-masked]>
Date: Thu, 9 Jan 2020 01:36:32 +0000

I think I agree with everything Ned said below. :)

Dave

-----Original Message-----
From: Smith, Ned <[email-masked]> 
Sent: Wednesday, January 8, 2020 5:34 PM
To: Dave Thaler <[email-masked]>; Michael Richardson <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: "Schönwälder, Jürgen" <[email-masked]>; [email-masked]
Subject: Re: [Rats] looking for better terms -- request for bike shed discussion

-Ned

    

    
    Dave
    
    -----Original Message-----
    From: RATS <[email-masked]> On Behalf Of Michael Richardson
    Sent: Wednesday, January 8, 2020 11:35 AM
    To: Laurence Lundblade <[email-masked]>
    Cc: =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?= <[email-masked]>; Smith, Ned <[email-masked]>; [email-masked]
    Subject: Re: [Rats] looking for better terms -- request for bike shed discussion

    

    

    

    
    
    _______________________________________________
    RATS mailing list
    [email-masked]
    https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C3ca5bb5fc5d84a6f6f6208d794a4120a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141304715148942&amp;sdata=2LW6xIN2AAm7bkYQIlpqGQRTwT76Bp0GYqxQbIbN3UM%3D&amp;reserved=0

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 9 Jan 2020 14:08:14 +0000

I agree with Ned, "attester" should be the device/endpoint.

I'd like to try to use this idea to explain the confusing terms appeared in my composite device PR. I'll use the router to be the example. 

A router consists of several slots: one main control slot and some line-processing or feature-processing slots. Each slot has a TPM and a CPU and can do the measured boot within this slot. Therefore the remote attestation of the router should consider verifying all the slots.
The router is the "attester". For each slot in the router, it has an "attesting environment" (Root of Trust for Measurement) and several "target environment" (TPM, bootloader, OS, etc.), and this "attesting env" produces a set of "claims" about these "target env". 

One traditional method of doing remote attestation for this router may be the main control slot collects each set of "claims" which are separately produced by each slot, and puts all the "claims" together to be the "evidence" of the whole "attester" (maybe here some other operations like signature are also needed), then conveys the "evidence" to the "verifier" (only the main control slot can communicate with the verifier).

My PR (https://github.com/ietf-rats-wg/architecture/pull/13) wants to consider another method. The main difference is: after collecting all the "claims", the main control slot (the "attesting env" in it) can verify the "claims" of other slots and produces a different set of "claims" about the verification results, then it combines the original "claims" of its own and "claims" of the verification results of other slots to produce the "evidence".

So the "leader and subordinate units" are the slots of the router. The "attestation result of subordinate units" is just some sets of "claims" of the "Evidence of the Attester".

> From: RATS [mailto:[email-masked]] On Behalf Of Smith, Ned
> Sent: Thursday, January 9, 2020 9:34 AM
> To: Dave Thaler <[email-masked]>; Michael Richardson
> <[email-masked]>; Laurence Lundblade <[email-masked]>
> Cc: [email-masked]; "Schönwälder, Jürgen"
> <[email-masked]>
> Equating the "attester" with an "attesting environment" may be fallacious.
> For example, the TA might be the thing that signs the conveyance protocol
> frames and delivers the cert chain to the Verifier. However, it (the TA) isn't an
> "attesting environment" it only ever is a "target environment".
> 
> The Verifier MUST(?) detect the DICE layering convention and walk the
> graph back to the original (root) "attesting environment". Even with DICE
> layering, there is still only a single "device" (endpoint) that the RATS Role
> will call "Attester" and it consists of multiple "attesting environments" and
> multiple "target environments" where some of these are both an "attesting"
> and a "target" environment during its lifetime.
> 
> It may be incorrect to say that the TA is the RATS "Attester" because the
> Attester is supposed to be a pledge that can prove it is a trustworthy
> endpoint to the Verifer. The endpoint isn't just the TA, it is the chain of
> things that anchors it to the first "attesting environment".
> 
> The root/anchor "attesting" environment relies on its mfg to establish trust
> using a mfg issued certificate that vouches for the process that
> manufactured it and likely issues an identity credential (IDevID). The IDevID
> allows the Verifier to disambiguate which of possibly multiple instances of
> Attesters it is talking to currently.
> 
> It seems reasonable that an EAT submod structure can be used to represent
> DICE layering (so could an X.509 certificate chain). However, a submod
> could also describe other relationships / decompositions of a
> multi-component endpoint. For example, if the OP-TEE consisted of
> multiple chips then there could be multiple vendors, part numbers etc.. and
> therefore multiple submods where all of them (likely) are "target
> environments".
> 
> DICE layering comprehends hierarchies too. If one of the OPTEE sub
> components had DICE capabilities it could become an "attesting
> environment" to one of the OPTEE chips (branches). But this more complex
> thing is still dependent on its path to the anchor/root "attesting
> environment" so it can't (in isolation) claim to be the "attester".
> 
> If the TEE was an SGX instead of an OPTEE, then the anchor "attesting
> environment" is SGX uCode rather than HW --> Trusted FW. The SGX
> "attesting" and "target" environments are orthogonal to the non-SGX
> "attesting" and "target" environments, but nevertheless part of an IA
> "device". It is possible therefore to have multiple "Attesters" in the same
> SGX-capable "device".
> 
> -Ned
> 
>     The full evidence is a DICE cert chain that has a set of claims for each
> cert in the chain, where each layer is an attesting environment for the
> subsequent layer (attested environment):
>     Using Laurence's terminology, I believe the suggestion is that attesting
> environment is an "attester" and an attested environment is a "target".
> Thus the example above has 3 attesters (Hardware, TFW, and OP-TEE), and 4
> targets (HW where target == attester, TFW, OP-TEE, and TA).
> 
>     Are you ok with saying that every claimset in a chain is from a separate
> "attester"?   I believe this is different from our current definition of
> Attester (which is the thing that sends the whole chain to a verifier), so want
> to confirm.
> 
>     Dave
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler
> %40microsoft.com%7Cb7301d9b535a436003db08d79471dc41%7C72f988b
> f86f141af91ab2d7cd011db47%7C1%7C0%7C637141089066538773&amp;s
> data=fynNh%2FKEJgaGj1fQNwQYBjdgxQE5XUFl%2BeyA0nOkpJs%3D&am
> p;reserved=0
> 
>

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 9 Jan 2020 11:50:44 -0800

i think term “target”, perhaps short for “target (attested) environment”, holds up no matter how we define attester and is easier to use and better than “attested environment”.

For “attester” I see two choices.

1) Refers to the aggregate

What Panwei and Net are leaning towards in this thread. There would be by definition, one attester per device.

An attester could be made up of a number of “sub-attesters” (or attesting environments) plus maybe some on-device verifiers depending on daisy-chaining design. One attester could be made by many OEMs.

2) Refers to smallest functional attestation block

This is the way I used it in my text. There can be many attesters in a device.

I propose we use the term “aggregate attester” or “whole-device attester” to refer to the combination of the (atomic) attesters.

I prefer 2). I think it is cleaner and is easier to understand, particularly for people first learning about attestation. I think it makes my single paragraph description clean. I think we will want to refer to the atomic attester much more often than the aggregate attester. It keeps the simple case simple; you only incur complexity when you have a complex use case.

I think the definition of a device is going to cause some trouble with 1). Is the device a car, or is it the entertainment box, the motor control…? Is the device the router card or the router?

I like the association of one signing key per attester, rather than an attester having a lot of signing keys from different manufacturers.

In certification, I think the atomic attester would be the thing you’d certify, particularly if you were doing common criterion. It would be much harder, maybe impossible, to certify the aggregate.

Here’s a comment Ned made that I’m confused about:
>> "attesting environment" it only ever is a "target environment”.

What is “signing conveyance protocol frames”? It kind of sounds like TLS or IPsec. If that’s it, then I’d call that conveyance protocol and say that is incidental to attestation architecture.

I think of all signing in RATS as attesting, so if this is signing a token, then it would make the TA an attester.

LL

> On Jan 9, 2020, at 6:08 AM, Panwei (William) <[email-masked]> wrote:
>

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 09 Jan 2020 15:24:21 -0500

I'm also good with Ned's description.  

Calling it out as the "Attesting Environment" and "Attester" clearly is useful to avoid future confusion (which is bound to happen when we start talking about turtles all the way down).

-- thomas --

-----Original Message-----
From: RATS <[email-masked]> on behalf of Dave Thaler <dthaler=[email-masked]>
Date: Wednesday, January 8, 2020 at 8:36 PM
To: "Smith, Ned" <[email-masked]>, Michael Richardson <[email-masked]>, Laurence Lundblade <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Schönwälder, Jürgen" <[email-masked]>
Subject: Re: [Rats] looking for better terms -- request for bike shed discussion

Dave

-----Original Message-----
From: Smith, Ned <[email-masked]> 
Sent: Wednesday, January 8, 2020 5:34 PM
To: Dave Thaler <[email-masked]>; Michael Richardson <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: "Schönwälder, Jürgen" <[email-masked]>; [email-masked]
Subject: Re: [Rats] looking for better terms -- request for bike shed discussion

-Ned

    

    
    Dave