RUCUS BOF -- Meeting Minutes
============================

Chairs: Hannes Tschofenig/Francois Audet

Meeting Minute Taker: Richard Barnes 

Agenda bash: 
JDR wants to make sure that there's at least an hour of discussion.  Hannes promises there will be.

IETF Exploratory Groups
Bernard Aboba
-- EG is between a BOF and a WG (RFC 5111)
-- Short lifetime, 6-12mo, one extension
-- Aggressively targeted toward creation of a WG
-- R. Barnes: Is this targeted at making a WG?
-- Peterson: Targeted at determining whether it makes sense to form a WG

Unwanted Communication Problem Statement
David Schwartz

-- Focus of unwanted communication, not just spam
-- Levels of "badness", from harmless (wrong number) to malicious
-- Hannes: Context is really important here
-- Henning: The classification of "badness" is an important 
-- Norreys: Can we expand on the "evil" thing later?  Need to make sure we keep technical aspects separate from legal aspects.

SIP and SPAM
Jonathan Rosenberg
-- Draft is an analysis of existing email techniques
	--> some of them are useful, some are useless
-- Current solution is centralized providers
-- Jennings: The important thing is that they charge money, not that they're centralized
-- Hoffman: Reputation and whitelists have a lot of overlap
-- Sinnreich: Will this protect us against telemarketers and political campaigns?
-- JDR: That's the subject of this BoF

SPIT archtitectural issues
Henning Schulzrinne
-- Need to talke about what parts of SIP are within scope
-- Revival of telemarketing, death of do-not-call lists
-- Botnets might be a dominant factor in the SPIT problem
	--> real or fake identities
-- Applicability of techniques depends on communications patterns
-- Hard to apply identity mechanisms effectively here
-- Lots of evolving mechanisms, need "glue" to hold them together
-- We should separate mechanisms from communications
-- Norreys: You were talking about message characteristics, how does that apply to VoIP?
-- Henning: Looking at not just a single call, but volumetrics, etc.  Could also use a guess as to the location of the caller

Lessons Learned from IETF Email Anti-spam Work
Jim Fenton
-- Anti-spam RG in the IRTF, MARID & DKIM in IETF
-- Change has to deal with legacy things, here both from e-mail and PSTN

Legal and Regulatory Considerations
John Morris
-- Laws won't do much against spam (hasn't for email)
	--> Won't hinder spam-fighting either
	--> As IP comms become more pervasive, they'll get more regulation
-- IETF can enable users to set rules/expectations that the law can enforce
-- Some spam is constitutionally protected (CAN-SPAM may be unconstitutional)
-- Avoid honeypots as a mechanism because governments can use them for censorship/surveillance

Discussion:
-- Hannes: Summary of the presentations
	-- Purpose of this group is to investigate architectural issues
	-- "What glue do we need?"
-- Schwartz: Keep the discussion of WG/EG for the very end.
-- Peterson: If we were talking about a WG, then we'd be doing something very different.
	-- Hope we'll be able to establish interest/relevance
-- Rosenberg: In the past there have been a lot of point proposals
	-- Need to step back and identify mechanisms
	-- E.g., is spam scoring worthwhile?
	-- This EG is the venue for those discussions
	-- Find a set of mechanims for which standardization might be viable
	-- Henning's "glue" is secondary, need mechanisms to connect
-- Aboba: EG process is short, so you need to contain the scope
	-- Literature review, instead of getting consensus?
	-- Goal of an EG is to tell ADs whether to form a WG
-- Worley: Seems like the first thing to do is assess efficacy of mechanisms against email spam
-- York: Agree with JDR that we should step back and look at architecture
	-- What are the ADs looking to see out of this group?
-- Peterson: Engineering is usually based on a solid, empirical problem definition
	-- Don't have much much experience with SPIT, so it's kind of theoretical
	-- Need to clarify assumptions behind mechanisms and validate them
	-- Needs to be a plausible story about what SPIT will look like and how to fight it
-- Schulzrinne: Problem with mechanisms is that it's really hard to test them well
	-- How many years ahead of the problem should we be?
	-- Also, early instances may be very different from eventual form
	-- If you wait too long, the technology's reputation can go down
	-- Cost of not doing something is very large
-- Jennings: This isn't so much about when we should act; VoIP is already getting spam
	-- Want to see that there's a practical argument that "if we did this, it might help"
-- Tschofenig: Given that we have limited resources, maybe we should pick a few mechanisms to look at
-- Schwartz: The problem does exist today.  We've connected a lot of customers to peering, 
	--> They're asking to be protected from unwanted comms
	-- To think that we'll find THE solution, the spammers with have gotten around it
	-- Need something like a policy framework that we can plug specific mechanisms and policies into
-- Dawkins: The EG should talk about how they intend to deal with the evolution of the problem
-- Hoffman: This is actually about reducing *receipt* of unwanted communications
	-- Empirically, filters don't reduce spam/unwanted communications
	-- You target market will change its desires based on the products you produce
-- Fenton: In some senses, this is a solution in search of a problem
	-- The tough decision will be trying to decide what the problem is
	-- Probably not the whole SPIT problem, but some stable subset of it
-- York: Hoffman is right that SIP only happens in small clouds right now
	-- This is a lot of what's preventing SPIT right now
	-- SPIT will get worse as more networks interconnect
-- Peterson: All this talk about a shifting problem makes me nervous as a manager
	-- Can we identify some stable characteristics that we can aim at?
	-- There's a reason this BOF is focused on "Unwanted Communications"
		--> SIP lacks an authorization mechanism
	-- Paul's observation about not stopping unwanted communications from being sent might not hold in real-time communications
		--> Communications are negotiated end-to-end before content flows
		--> This will come from an "authorization" approach
	-- Want to see people work on what the authorization story is
-- Aboba: JDR's draft talks about 3 types: Call/IM/Subscribe
	-- IM & Subscribe already exists in volume
	-- Hannes: Can you provide pointers?  
	-- Aboba: MSN has a huge problem with spam and malware-propagated spam
-- Henning: If we hadn't done *something* against email spam, email would be unusable and would die off
	-- Victory doesn't have to be total, just reducing the problem is good enough
	-- It's not just an authorization problem; we want to allow people I don't know to call me
	-- Need to facilitate communication with people we haven't met before
		--> pre-authentication ==> only closed user groups
-- ???: We've probably jumped to solutions too early in some cases
	-- Real-time nature of SPIT makes it much worse than SPAM; it interrupts, while SPAM doesn't
	-- Form a WG instead of an EG? 
		--> Cullen: We're not at that point yet
-- Schwartz: Black-listing is also harder to do here
-- York: Peterson is right that we need to look at identity and authorization
	-- With email, we had email first, then email spam
	-- We won't have the same luxury in SIP; the tech won't even get off the ground
-- Peterson: I was speaking of authorization in a broader sense than Henning claimed
	-- There are reputation/introduction based systems for bringing in new people
	-- I don't mean banning comms from people not on my whitelist
-- Henning: Also have many more options with how to handle a voice call
-- Elliott: Should be careful of going to fast
	-- You want to have an appropriate decision-making framework

-- Hannes: Do we have some specific deliverables?
-- Schwartz: Propose a use case document
-- Aboba: Because it's there to help the formation of a WG, shouldn't focus on things like architecture
	-- Might make more sense to look at experience, possible solutions
-- Rosenberg: Architecture doc doesn't make sense.  Need to demonstrate utility/applicability
-- York: Haven't we had a bunch of proposed solutions?
	--> Rosenberg: These are all too specific.  Need a higher-level discussion.
		-- Not "here's how to do a CAPTCH"; need "This is why CAPTCHAs are valuable"
-- Aboba: Really have to think about something that can be done in 6mo
	-- Might not want the sort of analysis that JDR is proposing
	-- More of a literature review, quick pro/con analysis
	-- Hannes: We already have a survey (JDR's doc)
-- ???: This sounds like it could be a show-stopper; can we get something done in 6mo?
-- Lepinski: Use cases are really important, need to use them as a basis
-- Jennings: The words "architecture" and "use case" are overused; what do people specifically want?
	--> Trust relationships
-- Hodges: Even going through use cases is useful
-- Rosenberg: Probably useful to have deployment scenarios, but not really related to formation of WG
-- Audet: If we use scenario in order to make the point about the feasibility of spam techniques, it's ok
	--> Don't focus on use cases by themselves 
-- Peterson: Bernard pointed out that you need to convince the ADs
	-- A picture of a federation is not convincing
	-- A picture with a story about how you fight spam/spit there is more convincing
-- Schwartz: Didn't mean that use cases are valuable per se, rather as a basis for analyzing spam threat
-- Rosenberg: Take existing drafts, tear out the specifics, and describe why it's a good idea in which scenarios
	-- Pros/cons/assumptions/constraints
-- Hoffman: If we do it that way, 2-page max on each submission

-- Hannes: Is there interest in starting an EG along the lines of JDR's suggestion
	-- Many in favor
	-- Henry Sinnreich against
		-- Most of the speakers here are too busy to actually put out a document or product
		-- This hurts the credibility of the group
-- Aboba: Need to be really specific about the goals, maybe want to make a summary of summaries with some aggregation/consensus