At 9:58 AM -0400 5/22/02, Abbie Barbir wrote:
Graham and all,
I am providing a summary of the current position and feedback.
This will be points that we try to get agreement on.
1. endpoint-user must be able to access OPES diagnostic
information using legacy s/w.
2. have no problem with protocol extensions being available to
facilitate access to the information.
3. not opposed to using In-band information even if it means extensions
4. keeping a log could be quite sufficient
5. having out of band access from one endpoint or the other is a far better
outcome than having none
6. (From mark baker) No need to standardize on a callout protocol.
Here I propose that we start a new thread where each point is
discussed and get solved.
abbie
Unless I've missed something (which is certainly possible), the draft
may want to suggest how the OPES architecture will respond to the
following IAB consideration:
(3.1) Notification: The overall OPES framework needs to assist
content providers in detecting and responding to client-centric
actions by OPES intermediaries that are deemed inappropriate by the
content provider.
The response may be that this consideration will be addressed in a
requirements document -- for example by requiring the initial request
from a client to a content provider to deliver a header flagging the
client-centric OPES action to be performed. Although such a header
may not have major "architectural" implications, in explaining and
understanding an OPES flow it seems appropriate to state that there
should be notice to the "other" primary party (i.e., the party not
initially requesting the OPES transformation) of the planned OPES
transformation or callout PRIOR to the transformation or callout
actually happening.
A small and unrelated point about 3.4 of the draft:
3.4 Privacy
Some data from data consumers is considered "private" or "sensitive",
and OPES processors must both advise the primary parties of the their
privacy policy and respect the policies of the primary parties. The
privacy information must be conveyed on a per-flow basis.
Especially as peer-to-peer technologies become more widely used,
there will likely be times that data providers also have private or
sensitive data. I suggest changing "data consumers is" to "data
consumers or providers may be."
John
----------------------------------------
John B. Morris, Jr.
Director, Internet Standards, Technology
& Policy Project
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
(202) 637-9800
(202) 637-0968 fax
jmorris(_at_)cdt(_dot_)org
http://www.cdt.org
----------------------------------------