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:
“Wake me when you’re done…” … A little charter-bashing session Rohit Khare, UC Irvine August 25, 1998 IETF-42 (Chicago, IL)
August 25, 1998NOTIFY BOF @ 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
August 25, 1998NOTIFY BOF @ IETF 42 (Khare)3 NOTIFY: A Consensus Charter èDefine a protocol to enable distributed event notification tools to be broadly interoperable
August 25, 1998NOTIFY BOF @ 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
August 25, 1998NOTIFY BOF @ IETF 42 (Khare)5 NOTIFY Charter: Out of Scope zCreation of new authentication schemes zDescription of message transformation functions zDefinition of schema-specific notifications
August 25, 1998NOTIFY BOF @ 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)
August 25, 1998NOTIFY BOF @ IETF 42 (Khare)7 NOTIFY Charter: Milestones zSep 98 -- Create scenarios and requirement documents; submit as Internet Drafts zNov 98 -- Create event notification protocol specification document; submit as I-D zDec 98 -- Meet at Orlando IETF to discuss zMar 99 -- Meet at IETF to discuss zApr 99 -- Create final scenarios and requirement documents; submit as Informational RFCs zJul 99 (Oslo) and Nov 99 (DC) -- Meet, discuss zDec 99 -- Submit final protocol spec as RFC
August 25, 1998NOTIFY BOF @ 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
August 25, 1998NOTIFY BOF @ 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?
August 25, 1998NOTIFY BOF @ 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?
August 25, 1998NOTIFY BOF @ 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
August 25, 1998NOTIFY BOF @ 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.
August 25, 1998NOTIFY BOF @ 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
August 25, 1998NOTIFY BOF @ IETF 42 (Khare)14 PAGER: A Campaign Platform zA charter I’d be willing to commit to myself.
August 25, 1998NOTIFY BOF @ 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”
August 25, 1998NOTIFY BOF @ 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)
Your consent to our cookies if you continue to use this website.