* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

IETF 71 (Philadelphia)

Proposed BOFs (not necessarily officially approved):



  • Procedures Update for IETF (PUFI)
    • Status: Approved (after significant revision)
    • Slot duration: 2 hours
    • BOF chair: Pete Resnick
    • Responsible AD: Russ Housley
    • Discussions: ietf@ietf.org (unusual, but this is the right place)
    • Summary and scope: The recent IETF Last Call for draft-carpenter-rfc2026-changes has shown that many people active in the IETF community are wary of changing the IETF procedures without a very thorough discussion. Yet, the POISED WG and the NEWTRK WG efforts showed that it is indeed difficult to craft new procedures and then obtain IETF consensus for them. While there does not appear to be consensus to adopt all of the changes in draft-carpenter-rfc2026-changes, there does appear to be support for some of the changes. The objecteive of this BOF is to determine which of the proposed changes have broad community supprort. The intent is to generate a document that can be easily approved as an update to RFC 2026 that contains only the proposed changes with broad community supprort.


No BOFs requested at this time. However, CSI is likely a WG by IETF-71, SAVI might be, and so might TICTOC. If these fail to become WGs, there is a (small) likelihood that the ADs may schedule some of them as repeat BOFs. Finally, there is one known BOF effort, multimob, that is in theory up for consideration. However, there has been very little action since IETF-70 MOBOPTS meeting and to date there is no request.

Operations and management


The chairs of the BOF from previous IETF meeting will work to redraft the existing proposed charter into a more formal document with goals and milestones that can be discussed on this list. David Schwartz and Ed Lewis are working to combine their PEPPERMINT problem statement drafts into a single proposal for discussion.

Chairs: Hannes Tschofenig/Francois? Audet

BOF Date: 10-Mar-2008

The topic of dealing with unwanted traffic in SIP has surfaced several times in the IETF in the context of preventing Spam for Internet telephony. Previous attempts to have a structured discussion about this topic have (among other reasons) failed due to the strong focus on selected solution approaches.

Prior work in SIP on identity management has an important role in this activity since a strong identity mechanism in SIP has been seen as a prerequisity for establishing authorization policies. Hence, the "Discussion and Analysis of SIP Identity" (DASI) BoF is relevant for this event. Even though there is no direct dependency between the two activities the number of interested participants will quite likely overlap.

This BoF focuses on the discussion of architectural aspects. The underlying theme is that the work on building blocks is more fruitful once the larger framework is understood. A number of solutions components have been submitted to the IETF, have been published in the academic literature and found their way into other standardization bodies. Reduce unwanted communication requires authorization decisions to be made. These decisions can be made based on individual sessions but also on the interaction at a higher granularity (e.g., the interaction with a specific VoIP provider network). Examples of questions with relevance for an architecture might be:

  • Where does information for decision making come from?
  • What are useful information items for decision making?
  • Where are policy decision points located? What about the placement of policy enforcement points?
  • Are privacy aspects to consider with the exchange of information?
  • How does the underlying trust model look like?
  • What assumptions are certain mechanisms based on?
  • Can individual proposals be combined in a reasonable way?


It is not the aim of the BoF to discuss specific solution approaches since it is likely that multiple techniques have to be used in concert.

'BoF Goals

Determine whether there is interest in the community to investigate the architectural approaches surrounding the reduction of unwanted communication in SIP.

Discuss the next steps for work within the IETF. One possible approach is the formation of an Exploratory Group, an experiment that is layed out in RFC 5111, to investigate requirements and the architectural background. This initial step should produce a roadmap for further work on necessary solution components.


Agenda discussions can be found on the mailing list.

'Charter Text

---Proposals for the charter text can be found on the mailing list.---

The Session Initiation Protocol (SIP) defines a system for user-to-user multimedia communications. Therefore, it is susceptible to unwanted communication attempts. RFC 5039 analyzes the problem of spam in SIP and examines various possible solutions that have been discussed for email and considers their applicability to SIP.

RFC 5039 gives good, high-level recommendations regarding future work, namely

  • Strong Identity
  • White Lists
  • Solve the Introduction Problem
  • Don't Wait Until It's Too Late

Among the many individual solution building blocks that are discussed in RFC 5039 (including content filtering, black lists, white lists, consent-based communication, reputation systems, address obfuscation, limited use addresses, turing tests, computational puzzles, payments at risk, circles of trust, and many others) there is no framework outlined how various mechanisms work together to produce a complete solution nor does the document attempt to offer a ranking to determine which solutions could form an initial set of candiate for subsequent standardization.

This exploratory group chartered for one year aims to create a venue where discussions on unwanted communication in SIP can take place. The main goal of the group is to produce an architecture document that sheds light on the interworking between a minimal set of building blocks.

The group will consider prior work on SIP identity and related techniques and will consult with privacy experts to deal with the legal aspects of filtering communication attempts.


Mar 08 BoF @ IETF#71

Jul 08 Formation of an exploratory working group

Jan 09 First WG draft on the architecture document

Jun 09 Submit architecture document to the IESG for consideration as informational RFC

Jul 09 Close group and decide on future work


[RFC 5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008.

[draft-tschofenig-sipping-framework-spit-reduction] H. Tschofenig, H. Schulzrinne, D. Wing, J. Rosenberg and D. Schwartz: "A Framework to tackle Spam and Unwanted Communication for Internet Telephony", draft-tschofenig-sipping-framework-spit-reduction-03.txt (work in progress), Feb. 2008.

[draft-niccolini-sipping-spitstop] S. Niccolini, J. Quittek: "Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario", draft-niccolini-sipping-spitstop-01.txt, (work in progress), Feb. 2008.



  • Key Management for Routing and Transport Area Protcols (KMART)

Automated key management mechanisms are needed to support routing and transport protocols. While development of such mechanisms is a core responsibility of the Security Area, active collaboration with routing and transport area experts is essential. This work cannot succeed without a clear understanding of the protocols, operational requirements, and associated interfaces that have and are being standardized in the routing and transport areas. This BOF will review currently defined and evolving requirements (e.g., the TCP-AO mechanism) to determine whether the problem(s) is well enough defined to begin work on key management mechanisms for one or more protocols. This BOF is not a working group forming BOF, but is expected to lead to formation of one or more working groups or design teams as requirements mature.


No BOF requested