On Wed, 5 May 2004, Abbie Barbir wrote:
Please publish the following draft-ietf-opes-end-comm-07 as a WG
Draft.
Abbie,
Thanks for making the edits! They seem to address Allison
Mankin's DISCUSS item (which is already cleared from the IESG review
record). We still need to address Ted Hardie's DISCUSS items, right?
I have already proposed the text for Ted's second DISCUSS and Markus
supported its addition to the existing wiretapping paragraph:
Following an IETF policy on Wiretapping [RFC2804], OPES
communication model does not consider wiretapping requirements.
Nevertheless, the documented threat is real, not obvious, and
OPES technology users operating in wiretapping or similar
logging environments should be aware of it.
Unless there are any objections, could you please incorporate that?
As for the first DISCUSS item, the situation is more difficult. I
recall that we struggled a lot with whether bypass should generate
errors when no OPES content is available. I still think we made the
right decision, although I regret not adding another bypass feature
with Ted's semantics. It did not occur to me at the time that we can
have it both ways if we have two features! Don't worry, I am not going
to propose adding more features at this point :-).
At the end of this message, I collected a few past remarks related to
this issue. It may be a good idea to contemplate them if you disagree
with my proposal/assessment.
I propose to address Ted's concern by adding the following two
paragraphs at the end of Section 4 preamble (just before 4.1):
Bypass feature is to malfunctioning OPES services as
HTTP "reload" request is to malfunctioning HTTP caches. The
primary purpose of the bypass is to get usable content in
the presence of service failures and not to provide the content
consumer with more information on what is going on. OPES
trace should be used for the latter instead.
While this work defines a "bypass service if possible" feature,
there are other related bypass features that can be implemented
in OPES and/or in application protocols being adapted. For example,
a "bypass service or generate an error" or "bypass OPES entity
or generate an error". Such services would be useful for debugging
broken OPES systems and may be defined in other OPES
specifications. This work concentrates on a documenting a
user-level bypass feature addressing direct IAB concern.
Does the above seem like an appropriate response to Ted's concerns?
Thanks,
Alex.
P.S. Here are a few relevant remarks from the F2F meeting notes:
Sally Floyd: ... The IAB document does not mean "user has to have a
way to bypass firewalls, boundaries, etc." It is saying, "If a user
asks for content from web server, and the content gets mangled by an
OPES server, then user needs to be able to figure out what went
wrong."
w.r.t. OPES bypass - Sally Floyd: Source of IAB concern about
non-OPES is data integrity, e.g., how does one detect malicious
transformation of data.
Here is a relevant comment from one of the earlier draft reviews:
[S19: Does bypass semantics mean "give OPES version if non-OPES is
not available" or "give an error if non-OPES is not available"? This
is very important to document clearly because it affects bypass
design/rules a lot.]
Our current rules are more-or-less clear but note that I claimed that
the decision will affect other rules. I wish I were more verbose at
that point.
Here is a relevant IAB draft change log entry:
* Be careful not to imply that all OPES intermediaries must obey
bypass instructions. Bypass should be ignored when no non-OPES
version of the content exists. Ideally, this may need to be
polished further -- if there is no non-OPES version of the
content, most IAB considerations probably do not apply because
there is really no adaptation, only creation of content (and we
should not restrict content creation).