Aggregated Service Discovery BoF IETF 86, Orlando Tuesday, March 12, 2013, 09:00-10:20 Chair: Peter Saint-Andre Scribe: Stuart Cheshire Mail: mailto:aggsrv@ietf.org Archives: https://www.ietf.org/mail-archive/web/aggsrv/current/maillist.html Chat: xmpp:aggsrv@jabber.ietf.org?join Audio: http://ietf86streaming.dnsalias.net/ietf/ietf863.m3u Slides: https://datatracker.ietf.org/meeting/86/materials.html#aggsrv Notes: http://etherpad.tools.ietf.org:9001/p/notes-ietf-86-aggsrv 1. Intro (09:00-09:05, 5 minutes) - Chair 2. Problem Statement (09:05-09:15, 10 minutes) - Andrew Biggs Manual configuration of service information in clients is onerous. Users are mobile. Correct configuration may be different in different places. DHCP, DNS SRV, DNS SD, Webfinger have limitations Dave Thaler Add two requirements: 1. Efficiency, e.g. caching, distribution to large number of clients 2. Easy to publish data as well as easy to consume data Peter Resnick This is not Service Discovery, it's Configuration Discovery How is it secure? Is client configured with credential that identifies itself? Tim Chown Need to be more explicit about context Similar to problems of using DHCP on multiple interfaces John Klensin Please comment on how this relates to IMSP/ACAP Configuration Discovery mechanisms Why did those fail and how is this different? Henning Schulzrinne Separate out use the cases Requirements are quite different in different use cases Anonymous user (e.g. random IETF attendee) has no common cross-service credential Joe Hildebrand ACAP is too complex Cyrus Daboo ACAP is read/write This is proposed to be read-only Dave Thaler The Problem Statement offered solutions but didn't state the problem Joe Hildebrand This is about discovering information specific to a particular user (e.g. host and port for their mail server) not discovering information specific to the local network they currently happen to be on. John Klensin This sounds just like ACAP Mike Jones, Microsoft This sounds just like Webfinger Cyrus Daboo This is not about reinventing existing functionality, like HTTP redirect Henning Schulzrinne There are two ways of doing this: A central OS-supported way of getting all information A per-application mechanism 3. Aspects of the Solution Space (09:15-09:35, 20 minutes) a. Possible Document Format (09:15-09:25, 10 minutes) - Cyrus Daboo https://datatracker.ietf.org/doc/draft-daboo-aggregated-service-discovery/ Pete Resnick How would DHCP work for any of this? Cyrus Daboo For bootstrap when you first bring a new device into your company Pete Resnick So scope is not per-application; it's all the services that use the same identifier Cyrus Daboo e.g. set up all Yahoo services at once Pete Resnick There's conceptually a 'parent' application Joe Hildebrand This doesn't require an OS-level service There are protocol clusters, e.g. Mail client uses IMAP, SMTP, LDAP, etc. John Klensin What is the input to this? Cyrus Daboo User identifier John Klensin Then there are two problems Two services may use the same identifier, and that causes privacy problems Joe Hildebrand Intent is that all services which use the same identifier are run by the same organization John Klensin What does an email address mean? Sub-addresses? Henning Schulzrinne This won't work for home users (Huh? I don't know what that means.) Mike O'Reirdan I want this to enable a bank to discover which of their customers' computers have viruses on them and them to go to a remediation service John Klensin This sounds a lot less capable than IMSP Or is it going to end up like ACAP? Need more clarity Document Format presentation continues... Elliot Lear How often is this query done? On account setup? Every boot? Periodically? Cyrus Daboo On account setup, and may be triggered after a failure Kerry Lynn Seems to assume one-writer of the service file What if you have many service providers? Cyrus Daboo Different providers need to use different user identifiers b. Relationship to WebFinger (09:25-09:35, 10 minutes) - Paul Jones https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ Joe Hildebrand Depends on what the users views as a set of related services John Klensin If I'm a user of this, I may user different providers that I don't trust to share information This doesn't sound very efficient Joe Hildebrand Just because it can be deployed inefficiently doesn't mean it should be -- Questions to be answered - moderated by Chair Do we have a well-scoped problem statement? Hum for yes: weak Hum for no: loud Could we get to a well-scoped problem statement in six weeks? Hum for yes: moderate Hum for no: almost none Hum for unsure: moderate Is there at least a nub of an interesting problem here? About 25 people raised hands Pete Resnick: We need another iteration on the list