[Aggsrv] BoF minutes

[Peter Saint-Andre <[e-mail]>]

With many thanks to Stuart Cheshire for scribing, here are minutes for
the BoF at IETF 86...

https://www.ietf.org/proceedings/86/minutes/minutes-86-aggsrv

###

Aggregated Service Discovery BoF
IETF 86, Orlando
Tuesday, March 12, 2013, 09:00-10:20

Chair: Peter Saint-Andre
Scribe: Stuart Cheshire

Mail: mailto:[e-mail]
Archives: https://www.ietf.org/mail-archive/web/aggsrv/current/maillist.html
Chat: xmpp:[e-mail]?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

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/