The exception InputFormatError is only raises by one operation,
set_evaluators_by_pattern. I don't understand why this would not raise the
same exceptions as add_evaluators_by_pattern or
delete_evaluators_by_pattern. They all have the same input parameters.

resolved

Some of the exceptions defined could use names that are less like to
conflict with standard language objects and thus would not have to be fully
qualified. For example, InternalError conflicts with
java.lang.InternalError. Perhaps RadInternalError might be nicer.
ComponentError might be another candidate for RadComponentError.

resolved

In multiple places in the IDL (struct AccessDefinition,
AccessDecision::access_allowed) the following is used:

Operation operation;

This is invalid IDL despite the fact that many IDL compilers accept this
today.

resolved

The DynamicAttributeService was designed to allow modification of
SecAttributes prior to locating and using PolicyEvaluators. These
modifications are application are most likely specific in nature.
Unfortunately the entire service can only have one DynamicAttributeService,
therefore, instance of RAD service have to be partitioned for different
applications. It might have been better to have associations with
ResouceNames such as was done with PolicyEvaluators. Another alternative
might have been to associate a DynamicAttributeService with a combinator,
since different resource names can use different combinators this implies
they also could then have different DynamicAttributeServices. This is
probably not an important issue, but it can dictate how applications must
deploy instances of the service.

Close this issue with no change.

The number of security policies supported by a PolicyEvaluator could be
arbitrarily large. Because of this the operation "list_policies" in the
PolicyEvaluatorAdmin interface might be changed to:

PolicyNameIter list_policies(in num_ret, in max_iter, out
PolicyNameList policy_names);

where max_iter is maximum number of entries held by the iterator, num_ret
is the maximum number of entries returned in the "out PolicyNameList list"
argument, and "policy_names" is sequence of PolicyNames having at most
"num_ret" entries. If the list of policy names has less than "num_ret"
entries, the iterator will be nil.

The iterator interface would look like:

interface PolicyNameIter

;

Note this technique could be carried to the extreme for all those
operations that return a PolicyEvaluatorList. However, it seems less likely
that one would has assigned large numbers of evaluator in the same way one
might have large numbers of security policies.

resolved

>You have probably already caught these problems. Just in case you haven't I
>am sending a modified copy. Mainly problems with missing or extra forward
>declarations.
>
>You can probably ignore the 'include "cds_patches.idl". We are not using a
>2.3 orb so we had to define some types that were needed by the 2.3
>security.idl.

resolved

Due to very scetchy issue descriptions the document will be handled as 1 issue. The complete doc can be found in the issues archive

No Data Available

The following operations in the EntityFactory Interface need adjustment to correctly generate geometries:

For EntityFactory::index_bodies():
LongSeq index_bodies(in LongSeqSeq oriented_shells);

The oriented_shells data must be in the form: LongSeqSeq as showns above.

LongSeq index_faces(in LongSeqSeq oriented_eloops, in LongSeqSeq vertex_loops,
in LongSeq surfaces);

The vertex_loops data must be in the form: LongSeqSeq as shown above.

Also, the name used for the first argument to index_oriented_shells() is misleading:
LongSeq index_oriented_shells(in LongSeq ofaces, in BooleanSeq sense);

ofaces should be shells.

The recommended changes are made as suggested in the summary

In the text of the RAD document formal/2001-04-01, there is reference to the multiple_evaluate() method
of the PolicyEvaluator interface, but it is not defined in the IDL.

It seems to me that RAD may need to use RAD to provide access control over certain ResourceNames (particularly for the administrative interfaces, where some folks may own portions of the ResourceName namespace. Has anyone tackled this? It seems to me that it is a useful (and perhaps vital) effort.