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

2. IETF 49, San Diego Agenda Introduction (2 min) WREC Status (13 min) Intermediary Discovery and Description (20 min) Resource Update Protocol (20 min) Conclusions / Next Steps (5 min)

3. WREC Working Group IETF 49, San Diego WREC Status New Co-Chairs Known-Problems update Taxonomy update WREC wrap-up Motivation for New Work Proposal

4. WREC Working Group IETF 49, San Diego 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)

5. WREC Working Group IETF 49, San Diego 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

6. WREC Working Group IETF 49, San Diego 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

7. WREC Working Group IETF 49, San Diego 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

8. WREC Working Group IETF 49, San Diego 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

9. WREC Working Group IETF 49, San Diego Intermediary Discovery & Description Background Scope Design Goals Issues – Discovery Issues - Description Next Steps

10. WREC Working Group IETF 49, San Diego 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

11. WREC Working Group IETF 49, San Diego 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

12. WREC Working Group IETF 49, San Diego 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

13. WREC Working Group IETF 49, San Diego 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

14. WREC Working Group IETF 49, San Diego 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)

15. WREC Working Group IETF 49, San Diego 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)

16. WREC Working Group IETF 49, San Diego IDD - Description Issues Describing behaviors (fail-over, load balancing, etc.) Describing locality (clients and intermediary proximity on network) Determining precedence Description format – XML?

17. WREC Working Group IETF 49, San Diego IDD Components

18. WREC Working Group IETF 49, San Diego 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

19. WREC Working Group IETF 49, San Diego Resource Update Protocol Background Scope Design Goals Use Cases Issues Next Steps

20. WREC Working Group IETF 49, San Diego 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 )

21. WREC Working Group IETF 49, San Diego 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

22. WREC Working Group IETF 49, San Diego 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

23. WREC Working Group IETF 49, San Diego RUP – Use Case Examples Cache invalidation Cache delta update Cache multiple object update Processing instructions for surrogates Client update (search engine, ‘bot, etc.)

24. WREC Working Group IETF 49, San Diego RUP – Issues Managing state on servers Choice of transport Resource grouping (channel description) Announcement mechanism(s) Subscription mechanism(s) Reliability mechanism(s)

25. WREC Working Group IETF 49, San Diego announcement metadata / state subscription reliability http header well- known location … invalidationupdate / delta … XML? URISpace? XML Protocol / SOAP? BXXP? framework application RUP Components update message channel resource selection

26. WREC Working Group IETF 49, San Diego 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

27. WREC Working Group IETF 49, San Diego 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}