Subject: [Crisp] controls in IRIS

From: David Blacka <[email-masked]>
Date: Fri, 9 Apr 2004 18:21:40 -0400

I realize that this is officially past WG last call, but this is the sort of 
thing I only notice when I try to implement the specification.

I'm currently struggling with architecting <control> and <reaction> elements.  
After noodling about with this for (an admittedly) short time, I've come to 
the following conclusion:

As currently specified, controls may only be (sensically) defined at the 
IRIS-core level: that is, as features that *all* registryTypes nominally 
support.

In this sense, whether or not a server accepts a control or not is entirely a 
policy decision, and not based on what registryTypes the server happens to 
support.

If the intent was to create a mechanism for registryTypes to exend for 
themselves, then the location of the control element is not optimally placed.

For that situation, one of the following things must occur:

1) rules should be described on how to deal with controls that only apply to 
some subset of the searchSets present in a request.  Currently, this is 
totally unspecified.

2) the control element should be moved into the searchSet element, thus making 
it possible to be registryType specific.

3) or, we could do nothing and Let Chaos Rule!

At the moment, I cannot see what advantage controls gain by being placed at 
the level of the request rather than the searchSet.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: Andrew Newton <[email-masked]>
Date: Sat, 10 Apr 2004 12:24:39 -0400

This seems to be supposing an operator unfamiliar with the types of 
registries being run and the types of controls and policies being 
enforced by their own server -- a situation that is not probable.  
Getting into a situation where a server does not understand the 
controls it implements vs the registries it implements seems to me to 
be an implementation issue.

By keeping the controls at the request level, a server must only 
process the control against authorization once.  Putting it at the 
search set level means the server must do this checking multiple times 
per request.  Additionally, controls are a client initiated mechanism 
(unlike bags), and it is unlikely that an end user desiring policy 
exception processing based on their accepted level of access means for 
this exception state to be applied to some searches and not others.

-andy

---

From: David Blacka <[email-masked]>
Date: Sun, 11 Apr 2004 02:21:28 -0400

Again, I realize that I'm posting after the end of last call (which was 
April 6, I think).  The working group can tell me that a) this is not 
an issue (I think I could be convinced), or b) it may be an issue, but 
since we are passed last call, we aren't going to talk about it.  But 
absent any other input, I will continue to discuss this issue.

> be an implementation issue.

I don't *think* I supposed this, but maybe I did.  I think I can see 
how, in some sense, this is all an implementation issue, as any 
particular way of handling controls will be indistinguishable from 
"policy".

However, I think (and I could be mistaken), my concerns are not just 
implementation issues, as they effect client expectations.

> this exception state to be applied to some searches and not others.

I didn't understand this paragraph.

However, it is possible that my main concern is fairly easily remedied.

First, some background.  Although iris-core-05 doesn't really have any 
text about this, it is fairly obvious that the <control> mechanism 
described is intended to be extended without versioning.  I say this is 
obvious because that is only reason that I can see for allowing 
elements from any namespace in the <control> element.  Also, since 
there is no text describing, precisely, what controls *are*, I imagine 
them to be, generically: something that alters the behavior of queries. 
  In general, I would expect controls to be applicable to all queries 
for a registryType(s), and to be somewhat orthogonal to the queries 
themselves.

So my base question comes down to: what happens when a control is 
provided that isn't defined for all of the queries in the request?  
This question will come up the first time someone defines a new 
control, I think.  The problem is really just lack of specification.

I think that decent behavior can be specified fairly easily, though.  I 
think iris-core should say something vaguely like:

Servers accept or reject controls based on policy and on whether or not 
the server has ever heard of a particular control [it sort of already 
says this, I think].  Servers should accept or reject the control 
independently from the rest of the request (i.e., the queries 
themselves).

When processing a searchSet, if the control is not defined for the 
target registryType, then the control is simply ignored.

Clients SHOULD only include a control when that control is defined for 
all target registryTypes in the request.  (That is, clients SHOULD NOT 
put themselves in a situation where the control will be ignored). [This 
rule is probably not absolutely necessary]

And section 7.1 should add a requirement for registryTypes to declare 
what controls are supported.

In addition, I think we need to specify what should happen if a control 
is rejected.  Does the server then process the request of the request 
as if the control did not exist?  Or does it stop and return an error?  
If so, what does this error look like?

I think the answer to this is that servers MUST not process the rest of 
the request, and return some sort of response that includes the 
reaction and probably an empty <resultSet>.

I think this last point is sort of important, as I think without it 
<onlyCheckPermissions/> could be pretty annoying to use, as I'm pretty 
sure that if I'm probing a server with the <onlyCheckPermissions/> 
control, I really don't want results back, no matter what.

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 13 Apr 2004 12:08:36 +0200

David,

> Also, since

Section 3.1: "[...] This child element allows a client to signal to a 
server the desire for special states or processing"
The formulation is pretty abstract, but it's the definition we have and 
which your understanding of it has well covered.

> provided that isn't defined for all of the queries in the request?
[...]
> If so, what does this error look like?

Admittedly, section 3.3.8 doesn't address these (rather unlikely) points 
and leaves imagination of implementors open. I would like to add some 
wording, if we are still in time.

Regards,
Marcos