RE: PD 0126: Administrator-entered Code Used To Meet SFRs

["Daniel P. Faigin" <faigin@aero.org>]

On Wed, 12 Apr 2006 11:08:11 -0400 (EDT), "Arnold, James L. Jr."
<JAMES.L.ARNOLD.JR@saic.com> said: 

> However, it seems Dan thinks the difference between code and data is
> clear, but I tend to think it is not.

> I think there is a whole spectrum of scenarios:

> - Type in a bunch of code, compile it, and link it.
> - Follow a bunch of instructions to download and install a pre-built
> feature.
> - Type in a few lines of script/procedure to be interpreted by the rest
> of the TSF.
> - Define a rule to be enforced by the TSF.
> - Simply enter the limit you want enforced.

> I think the PD seems to be intended to prevent at least the first three
> examples. I'm not sure about the fourth, nor how it might be considered
> different from the third, though the last example would clearly be
> allowed by the PD.

Well, as my name was brought up.

First case: problematic, due to the risk of typing errors.

Second case: Just fine.

Third case: Probably OK, but raises a slipperly slope to the first case.

Fourth case: OK.

Fifth case: OK.

> The issue is only here because a validator objected to something
> they didn't like with no real basis in the CC for that position. Perhaps
> guidance should be forthcoming regarding performance of misuse analyses.

The VALIDATOR followed the process. The VALIDATOR saw an issue about which
there was a question, wrote up their side, asked those with a contrary
position to write up their side as best possible, and submitted to the scheme,
being willing to live with whatever answer was received. 

Your disagreement is not with the VALIDATOR, who followed the process. Your
disagreement appears to be with the answer given by the scheme. This is why,
when submitting these questions to the scheme, you need to present a carefully
constructed argument to support your side when asked, so that the right answer
can be given the first time, and the right PD can be developed the first time.

Daniel