ietf 49 wrec

WREC Working Group: 

IETF 49, San Diego Co-Chairs: Mark Nottingham Ian Cooper mnot@akamai.com icooper@equinix.com WREC Working Group

Agenda: 

Agenda Introduction (2 min) WREC Status (13 min) Intermediary Discovery and Description (20 min) Resource Update Protocol (20 min) Conclusions / Next Steps (5 min)

WREC Status: 

WREC Status New Co-Chairs Known-Problems update Taxonomy update WREC wrap-up Motivation for New Work Proposal

Known-Problems Update: 

Known-Problems Update Document format has been updated Almost ready for 'working group' last call Revision 3 is public, revision 4 expected to be available around the end of this week (see Ian)

Taxonomy Update: 

Taxonomy Update RFC Editor sent back because: It used a number of URLs as references It appeared to quote I-Ds as normative references Has been fixed (hopefully) – returned to IESG Copied to WREC mailing list because it did not re-enter I-D queue

WREC Wrap-Up: 

WREC Wrap-Up Work items are nearing completion Group needed more focus; getting bogged down in completing work items 'Rechartering' to gather focus, get fresh start but still leverage WREC’s work

Motivation for New Work: 

Motivation for New Work WREC has identified issues in the Web infrastructure (known-problems) Community interest in tools that may be used to solve problems in the Web infrastructure

Proposal: 

Proposal Recharter WREC into WEBI (WEB Intermediaries) Work items: Intermediary Discovery and Description Resource Update Protocol Today: validation, scoping and determination of next steps Not today: specific proposals, low-level details Discussion encouraged, please keep comments topical and brief

Intermediary Discovery & Description: 

Intermediary Discovery andamp; Description Background Scope Design Goals Issues – Discovery Issues - Description Next Steps

IDD - Background: 

IDD - Background WREC identified issues with interception proxies Interception proxies are widely deployed because there is no standard, effective way to configure the use of a proxy

IDD - Background (2): 

IDD - Background (2) PAC is poorly defined- Javascript, different client behaviors WPAD is not widely deployed in clients – lack of integration into configuration format, too many options Additional identified problems might be addressed in a client configuration mechanism Solution needs to be standardized

IDD – Scope Discussion  : 

IDD – Scope Discussion  Describing network attributes and overlay of intermediaries as accurately as possible, to enable clients to correctly route requests Intermediary implies proxy, gateway or surrogate Client implies user-agent or intermediary Design for use in a single administrative domain Two components: Discovery and Description

IDD – Proposed Design Goals: 

IDD – Proposed Design Goals Automated – users should be passive; administrative tasks should be minimized where possible Efficient – don't want to broadcast Flexible – need to accommodate a wide variety of use cases Simple, lightweight to implement and deploy Leverage standards where possible

IDD – Use Case Examples: 

IDD – Use Case Examples SMTP-like deployment in clients – port 80 is blocked, users must go through intermediary Location of nearby surrogates Intermediary → intermediary configuration (mesh building) Location of service-specific intermediaries (OPES)

IDD - Discovery Issues: 

IDD - Discovery Issues Matching boundary of discovery to client deployment Ease of deployment / implementation WPAD good for information, but is not a starting point (draft-cooper-webi-wpad-00)

IDD - Description Issues: 

IDD - Description Issues Describing behaviors (fail-over, load balancing, etc.) Describing locality (clients and intermediary proximity on network) Determining precedence Description format – XML?

IDD Components: 

IDD Components

IDD - Next Steps: 

IDD - Next Steps Join WEBI Mailing List – webi-request@lists.equinix.com Document editors, reviewers, authors – see chairs Gather requirements from other groups Need vendor input and participation First deliverable is requirements document

Resource Update Protocol: 

Resource Update Protocol Background Scope Design Goals Use Cases Issues Next Steps

RUP - Background: 

RUP - Background Interest in distributing state/metadata from servers to clients: DRP (http://www.w3.org/TR/NOTE-drp-19970825.html) DOCP (http://hpl.hp.com/techreports/1999/HPL-1999-109.html) WCIP (draft-danli-wrec-wcip-00) Content Signals (draft-rzewski-cndistcs-00)

RUP – Scope Discussion: 

RUP – Scope Discussion Protocol in which an entity communicates state/metadata about groups of resources to subscribed clients Discussion: Communication predominantly server → client Describes attributes of multiple resources May be separated from resource authorities Authorization / authentication should leverage other work

RUP – Proposed Design Goals: 

RUP – Proposed Design Goals Modular, Generic – a standard framework to deploy applications that fit defined scope Extensible – should be able to be used in unforeseen applications Leverage existing standards where possible Simple to implement

RUP – Use Case Examples: 

RUP – Use Case Examples Cache invalidation Cache delta update Cache multiple object update Processing instructions for surrogates Client update (search engine, ‘bot, etc.)

RUP – Issues: 

RUP – Issues Managing state on servers Choice of transport Resource grouping (channel description) Announcement mechanism(s) Subscription mechanism(s) Reliability mechanism(s)

RUP Components: 

http header well- known location … invalidation update / delta … XML? URISpace? XML Protocol / SOAP? BXXP? framework application RUP Components

RUP - Next Steps: 

RUP - Next Steps Join WEBI mailing list – webi-request@lists.equinix.com Document editors, reviewers, authors - see chairs Gather requirements from other groups First deliverable is requirements document Start gathering consensus about approach

Conclusions: 

Conclusions Review Charter WEBI mailing list – webi-request@lists.equinix.com Copies of presentation: In minutes At http://www.mnot.net/papers/ietf-49-wrec.{htm|ppt|pdf}