Subject: Request to publish: draft-ietf-opes-end-comm-07

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 5 May 2004 09:28:41 -0400

Please publish the following 

draft-ietf-opes-end-comm-07

as a WG Draft.

Thanks
Abbie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 5 May 2004 10:48:46 -0600 (MDT)

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