ietf-openproxy
[Top] [All Lists]

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

2003-10-21 10:30:41

see inline,

abbie

-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com] 
Sent: Tuesday, October 21, 2003 12:33 AM
To: OPES WG
Subject: feedback on draft-ietf-opes-end-comm-04


SNIP

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.


SNIP

the definition of "non-OPES" content is provider-dependent and may 
include content adapted by OPES.

I agree with the first part, but cannot concatenate that with 
the second part. Given an OPES-adapted content, a content 
provider may designate any other content as a non-OPES 
content, but that designated content cannot be OPES-adapted.



I see the confusion. I will fix it.

SNIP
 
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.

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. This may be obvious,
so i can deleted.

SNIP