Presentation is loading. Please wait.

Presentation is loading. Please wait.

“Wake me when you’re done…” … A little charter-bashing session Rohit Khare, UC Irvine August 25, 1998 IETF-42 (Chicago, IL)

Similar presentations


Presentation on theme: "“Wake me when you’re done…” … A little charter-bashing session Rohit Khare, UC Irvine August 25, 1998 IETF-42 (Chicago, IL)"— Presentation transcript:

1 “Wake me when you’re done…” … A little charter-bashing session Rohit Khare, UC Irvine August 25, 1998 IETF-42 (Chicago, IL)

2 August 25, 1998NOTIFY IETF 42 (Khare)2 NOTIFY BOF Charter-Bashing zNOTIFY: A Consensus Charter zWhat are we really trying to achieve? zWhat can we achieve, practically? yWhat real-world barriers do we face? yWho’s really gonna work on this? zWhat infrastructure do we take home? zPAGER: A Campaign Platform zComparison & Conclusions

3 August 25, 1998NOTIFY IETF 42 (Khare)3 NOTIFY: A Consensus Charter èDefine a protocol to enable distributed event notification tools to be broadly interoperable

4 August 25, 1998NOTIFY IETF 42 (Khare)4 NOTIFY Charter: In Scope zLatency: minimum and maximum bounds, for event observation and event delivery zDelivery: end-to-end or intermediated zInitiation: by sources or by sinks zConstraints: guarantees, transport choices, retry policies for disconnected clients and servers zNotification Management: subscriptions, coalescing, asynchronous callbacks, queue mgmt, security, group membership operations

5 August 25, 1998NOTIFY IETF 42 (Khare)5 NOTIFY Charter: Out of Scope zCreation of new authentication schemes zDescription of message transformation functions zDefinition of schema-specific notifications

6 August 25, 1998NOTIFY IETF 42 (Khare)6 NOTIFY Charter: Deliverables zScenarios document giving a series of short descriptions of how event notification service functionality can be used zRequirements document describing high-level functional requirements for event notifications, including rationale zProtocol specification (for example, describing new HTTP methods, headers, request bodies, and response bodies, to implement the event notification requirements)

7 August 25, 1998NOTIFY IETF 42 (Khare)7 NOTIFY Charter: Milestones zSep Create scenarios and requirement documents; submit as Internet Drafts zNov Create event notification protocol specification document; submit as I-D zDec Meet at Orlando IETF to discuss zMar Meet at IETF to discuss zApr Create final scenarios and requirement documents; submit as Informational RFCs zJul 99 (Oslo) and Nov 99 (DC) -- Meet, discuss zDec Submit final protocol spec as RFC

8 August 25, 1998NOTIFY IETF 42 (Khare)8 What are we really trying to achieve? zC’mon, guys: ONE SENTENCE zDoes it pass the Elevator test -- with an engineer? yEasy to sell the benefits yNot so easy to sell a mechanism

9 August 25, 1998NOTIFY IETF 42 (Khare)9 A 3-Layer Problem zWhat kind of Event Notifications? yDAV, IPP, Presence… yXML and other media types zWhat kind of Notification Management? yList callback-URIs, subscribe/unsubscribe operations yAccess Control zWhat kind of Notification Delivery? yPoll or Interrupt? End-to-end or Intermediated?

10 August 25, 1998NOTIFY IETF 42 (Khare)10 What can we achieve, practically? zDescribing a “notification queue” resource a la “collections” zJust using SMTP-to-the-endpoint, with SEND. z“Asynchronous” HTTP zSomething wonderful... zWhat real-world barriers do we face? zWho’s really gonna work on this?

11 August 25, 1998NOTIFY IETF 42 (Khare)11 zThe Masinter 13 zIdentifying the class of events for which notification is desirable zIdentifying the addresses of sources/sinks zDisabling notification zChanging the destination of an established notification zEnsuring notifications are not lost zPolling for missed notifications zRetransmission of notifications zSyntax zSemantics zSecurity considerations ySpam-proofing yRisks of false or dropped notifications yAuthentication, certified delivery yDelegation of notices to third parties

12 August 25, 1998NOTIFY IETF 42 (Khare)12 Real, Practical Constraints zFirewalls yThey keep us out for a reason, you know… yBut it should be easier to permit than deny zTransport Stacks ydon’t have slots to track millions of open TCP connections -- so UDP is needed even when reliability IS a concern. zSecurity yNeeds to integrate with what we have -- this does NOT merit a new scheme.

13 August 25, 1998NOTIFY IETF 42 (Khare)13 What infrastructure do we take home? zFrom the IESG’s perspective, what does the Internet gain as a whole? zThere’s no clean answer for server-initated application-layer messaging today zSynergy with Web Caching and Replication ycould be an ideal server-server cache update protocol zSingle-point of administration for firewalls ysimilar message formats and ports better than ad-hoc app protocols

14 August 25, 1998NOTIFY IETF 42 (Khare)14 PAGER: A Campaign Platform zA charter I’d be willing to commit to myself.

15 August 25, 1998NOTIFY IETF 42 (Khare)15 Comparison zPro: pins down a lot of the design decisions zCon: pins down a lot of the design decisions zPro: PAGER has a chair in sight zCon: PAGER has this chair in sight zProCon: does NOT stand for “Protocol for Applications Generating Events & Responses”

16 August 25, 1998NOTIFY IETF 42 (Khare)16 Conclusions zCompetency yAre we prepared to produce a practical protocol? zConsituency yWhich of us will build it? will use it? zCoherence yWhat style of document suite will explain it best? zConsensus yWhy can we believe corporate consensus is possible? y(From: “Advice to WG Chairs”, Schiller & Moore)


Download ppt "“Wake me when you’re done…” … A little charter-bashing session Rohit Khare, UC Irvine August 25, 1998 IETF-42 (Chicago, IL)"

Similar presentations


Ads by Google