IAB IAB Architectural Consideration for Architectural - - PowerPoint PPT Presentation

IAB IAB Architectural Consideration for Architectural Consideration for OPES OPES

Abbie Barbir

abbieb@nortelnetworks.com

Design Team

IAB consideration (RFC 3238) Brief Review of Some Issue

IP-layer communications

(2.2) For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user

• Make that mandatory (first HOP)
• How about NAT/Firewall issues
• Do we need to consider chained
• OPES intermediaries
• Callout Servers

IAB consideration (RFC 3238)

Data integrity with client-centric OPES services on responses

Notification Notification

(3.1) 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 (3.2) The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries

• Our interpretation is that OPES services

should, in so far as possible, make it easy to debug problems

• We defined explicit transformation notification as consisting
• f two parts:
• 1. “via headers” to include OPES intermediaries and callout

servers

• 2. Comments or embedded naming conventions with the

meaning “OPES service A transformed this element"

Tracing and Error detection Tracing and Error detection

• We ruled out automated semantic error detection,
• e.g., checking images for damage by broken compression

methods, malformed tags, etc.

Open Issues

• How can an origin server be made aware/trace errors

caused by an OPES intermediary, and

• How can an origin server specify bypass of OPES services?
• How can the OPES architecture not prevent users from

retrieving "non-OPES" version from the content provider?

• For example, an OPES intermediary might insert a

reference to an image into an HTML page;

• if it get the URL wrong, who will get notified about the

error and how will they trace it to the faulty intermediary?

• Basically, we need input/help

Basically, we need input/help

Possible Approaches Possible Approaches

1.

• 1. HTTP Extensions

HTTP Extensions

• Nasty (Yuk

Nasty (Yuk … …Not Again Not Again… …) ) 2.

• 2. Special OPES Headers in HTTP

Special OPES Headers in HTTP

• Less Nasty ???????

Less Nasty ??????? 3.

• 3. Authoring Tool

Authoring Tool 4.

• 4. Separate OPES Signaling Protocol

Separate OPES Signaling Protocol 5.

• 5. Try W3C for Error Reporting

Try W3C for Error Reporting 6.

• 6. Give UP

Give UP …… ……. .

The architecture document The architecture document

• 1. It needs substantial revision to include
• content path "traceroute",
• HTTP “via header” extensions,
• error notifications,
• bypass provisions,
• confidentiality and integrity
• 2. We need volunteers who have time to discuss and review the

architecture

Q&A Q&A