ietf-openproxy
[Top] [All Lists]

RE: feedback on draft-ietf-opes-end-comm-04

2003-10-21 11:09:18

On Tue, 21 Oct 2003, Abbie Barbir wrote:

OPES processor SHOULD be able to trace it's own invocation and
service(s) execution since it understands the application
protocol.

Is it a requirement or a consequence of the "since it understands"
part? There is another "SHOULD ... since"  requirement elsewhere
in the draft.


The since explains why the SHOULD was there in the first place. If still
unhappy can u reword please.

(1) Remove the informative "since ... " part
(2) Make sure the remaining requirement does not duplicate
    other existing requirement

An  OPES System MUST include information about its bypass policy.

An OPES System MUST identify the party responsible for setting and
enforcing the bypass policy.

An OPES System MUST include information that identifies, to a
technical contact, the OPES  processors involved in processing the
bypass request.

MUST include/identify where? In a trace? Then these should be
moved to tracing requirements.


Should be included in the OPES provider policy.

Including the last one? How do you include OPES processor IDs/info
into a provider policy? Also, how is the "provider policy" made
accessible? Is it a URI in a trace message?

OPES processor SHOULD be able to bypass it's own invocation

Isn't this a self-contradiction? Like lifting oneself by
one's own hair? If the processor is looking at the bypass
instruction, it is already invoked.



This means bypass services that it is responsible for.

Please reward "own" to "services" then.

Alex.