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

Timeframe IETF 80 (Prague)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 17:00 PT Monday January 31 (01:00 UTC Tuesday, February 1). The IAB and IESG will hold a joint teleconference to discuss the proposals. ADs will be expected to approve or disapprove the BOF request on that teleconferece, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before Thursday, 24 Feb. 2011.




Operations and Management

RENUM (Site Renumbering)


As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. Some would argue that the very design of IP addressing and routing makes automated renumbering intrinsically impossible. In fact, managers have an economic incentive to avoid having to renumber, and many have resorted to private addressing and Network Address Translation (NAT) as a result. This has the consequence that any mechanisms for managing the scaling problems of wide-area (BGP4) routing that require site renumbering have been dismissed as unacceptable. Even so, renumbering is sometimes unavoidable.
The task of the proposed RENUM working group is to identify specific renumbering problems in the context of site-wide renumbering, and to develop point solutions and system solutions to address those problems, or to stimulate such development in other working groups if appropriate. The principal target will be solutions for IPv6, but solutions that apply equally to IPv4 may be considered.

The appropriate area may be either Internet or Operations and Management.

BoF Chairs: Brian Carpenter (brian.e.carpenter@gmail.com), Tim Chown (tjc@ecs.soton.ac.uk)
BOF Proponents: Brian Carpenter (brian.e.carpenter@gmail.com), Sheng Jiang (shengjiang@huawei.com)
People expected: 100
Length of session: 2 hrs
Conflicts to avoid: Working Groups in the OPS, INT areas
WebEX: Requested
Responsible AD: Ron Bonica
Goal: Charter a WG
Agenda: See http://www.ietf.org/mail-archive/web/ietf/current/msg65918.html
Drafts: http://tools.ietf.org/html/draft-jiang-ipv6-site-renum-guideline ; also see RFC 5887.
Draft Charter: http://www.ietf.org/mail-archive/web/ietf/current/msg65918.html
Mailing List: renum@ietf.org
Mailing List Archive: http://www.ietf.org/mail-archive/web/renum/
Status: Approved

Protocol to Access WS database (PAWS)


As nations struggle to provide spectrum in a finite swath of useful spectrum, especially spectrum for use with wireless Internet bandwidth, there are problems with incumbents in a given band. The incumbents may use the spectrum inefficiently, especially geographically - there may be large swaths of country where a particular band is not used at all, and others where use is only in a portion of the band.

Recently, techniques have been developed that attempt to share spectrum between incumbents and new users. The generic term for this is "white space". For example, in over the air TV bands, spectrum is divided into channels, and in any one area, usually not all channels have TV transmitters in range. There is a desire among many regulators to make this prime spectrum available for Internet access and other uses, as long as the new use does not interfere with the existing TV band use.

The FCC (Federal Communications Commission) in the US has freed up its digital TV spectrum for unlicensed use and has crafted rules and regulations to be complied with. The available spectrum and associated channels for use vary on a regional basis. In the U.S., as in many other countries, there are other incumbents besides the television broadcasters. Spectrum and channel availability is dynamic, and use of spectrum requires verification of availability prior to use, and periodically on an ongoing basis. The U.S. regulator has decided that all new users of the TV band white space ("TV Band Device" or TVBD) must query a database with the location of the TVBD and receive from the database a list of available channels that it may use.

Multiple database(s) are expected to exist which contains the information about available channels for use at a given location. A device is required to query the database for available channels and associated information. There are several scenarios that the US regulation permits which include a simple tower/client arrangement where the tower queries the database on behalf of itself and its client TVBDs as well as ad hoc mobile networks where at least one TVBD in the ad hoc net has another path to the Internet and can query the database with it.

Since the regulatory databases are country-specific, the white space device needs to discover the relevant database.

While the information in the database is not particularly sensitive, there is interest by the incumbents and the regulator to assure that only authorized entities are involved in the transactions, and thus the transactions need strong authorization and integrity protection at least.

The air-interface technology for use in white space spectrum can vary. At the present time 802.11af and 802.22 in IEEE are working on specifications. Other technologies such as LTE or 802.16 may also be specified in the future.

Having a common IP based message interface between the device and the database will result in the ability of devices to access multiple databases and would also be applicable in different countries. It should be noted that while the US has specified regulations for the use of TV band whitespace, other countries and regulatory bodies such as OFCOM and CEPT are in the process of doing so. Details of the regulations in different countries may vary. However, the concept of a database listing incumbents and the need to query it to obtain information about available spectrum for use at a location is generic.

IEEE 802.22 has developed an interface that was specifically targeted at the U.S. TV Bands whitespace use. It is specific to the 802.22 mac/phy layer and to the US regulation. Co-ordination between IETF and IEEE to specify this interface that could be used by any air-interface technology would be useful.

This BoF proposes a work item to develop:

  1. A messaging protocol between a device and the database database 2. A mechanism by which the device can discover the available databases 3. Security for the protocol

BoF Chairs: Brian Rosen (Brian.Rosen@neustar.biz) Gabor Bajko (gabor.bajko@nokia.com)
BOF Proponents: Basavaraj.Patil@nokia.com
People expected: 75
Length of session: 1 hr
Conflicts to avoid: mext, netext, geopriv, ops-area, int-area, apparea, ecrit, dhc, 6man, v6ops
WebEX: No
Responsible AD: TBD
Goal: Charter a WG

  1. Overview and background of White space technology (15 Mins)
  2. Database architecture (10 Mins)
  3. Proposed charter and the work to be done in IETF (10 Mins)
  4. Open discussion (20)
  5. Conclusion (Show of hands/Hum)
    Draft Charter:
    Mailing List: paws@ietf.org
    Mailing List Archive: http://www.ietf.org/mail-archive/web/paws/
    Status: Approved


Real Time Communication on the World Wide Web (RTCWEB)

Description: Many implementations have been made that use a Web browser to support direct, interactive communications, including voice, video, collaboration, and gaming. In these implementations, the web server acts as the signaling path between these applications, using locally significant identifiers to set up the association. Up till now, such applications have typically required the installation of plugins or non-standard browser extensions. There is a desire to standardize this functionality, so that this type of application can be run in any compatible browser and allow for high-quality real-time communications experiences within the browser.
BoF Chairs: Harald Alvestrand and Ted Hardie
BOF Proponents: Harald Alvestrand and Cullen Jennings
People expected: 150
Length of session: 2.5 hrs
Conflicts to avoid: Working Groups in the RAI area (especially DISPATCH and CODEC), HYBI, TRILL, and ARMD
WebEX: No
Responsible AD: Gonzalo Camarillo
Goal: Charter a WG
Agenda: TBD
Drafts: draft-alvestrand-dispatch-rtcweb-datagram-00 and draft-alvestrand-dispatch-rtcweb-protocols-00
Draft Charter: See http://www.ietf.org/mail-archive/web/dispatch/current/msg03171.html
Mailing List: rtcweb@alvestrand.no
Mailing List Archive: See http://www.alvestrand.no/pipermail/rtc-web/
Status: Approved



JSON Cryptographic Syntax and Processing


JSON (an acronym for JavaScript Object Notation) is a text format for the serialization of structured data. It is derived from the JavaScript programming language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is language-independent, with parsers available for almost every programming language.
With the increased usage of JSON in protocols there is now also the desire to offer security services, such as encryption, and message signing, for JSON encoded data. The proposed working group aims to develop specifications to standardize these security services for JSON encoded data to improve interoperability, and to increase confidence in the offered security functionality based on the expert review process utilized in the IETF.

BoF Chairs: TBD
BOF Proponents: Hannes Tschofenig (hannes.tschofenig@gmx.net), Cullen Jennings (fluffy@cisco.com), Joe Hildebrand (jhildebr@cisco.com)
People expected: 80
Length of session: 90min
Conflicts to avoid: Working Groups in the SEC, RAI, APPSareas
WebEX: Yes
Responsible AD: Sean Turner'
Goal: Charter a WG or re-use existing working group
Agenda: TBD
Drafts: http://tools.ietf.org/html/draft-jones-json-web-token-01; other drafts in preparation
Draft Charter: See http://www.ietf.org/mail-archive/web/oauth/current/msg04948.html
Mailing List: currently the effort is discussed in OAuth (oauth@ietf.org)
Mailing List Archive: http://www.ietf.org/mail-archive/web/oauth/
Status: Not Approved

PLASMA - Policy Augmented S/Mime

Description: Current S/MIME mechanisms provide cryptographic access to the message

based on the identity of the recipient at the time of transmission. Any additional access control enforcement depends on the configuration of the recipients email client. Several Internet-Drafts have been submitted that establish a more robust access control mechanism where cryptographic access to the message is only granted after the access check.
This proposed working group would develop a framework for enforcing a more robust access control mechanism, based on existing CMS, S/MIME and SAML-based policy enforcement standards. The working group will also develop any necessary extensions to these base protocols specific to this problem space.

BoF Chairs: Paul Hoffman (paul.hoffman@vpnc.org), Alexey Melnikov (alexey.melnikov@isode.com)
BOF Proponents: James Schaad (jimsch@nwlink.com), Trevor Freeman (trevorf@exchange.microsoft.com), Patrick Patterson (ppatterson@carillon.ca)
People expected: 75
Length of session: 90min
Conflicts to avoid: abfab, kitten, karp, pkix, yam, eai, apparea, oauth, websec
WebEX: No
Responsible AD: Tim Polk
Goal: Charter a WG
Agenda: TBD
Drafts: http://tools.ietf.org/html/draft-freeman-message-access-control-req-00 "Requirements for Message Access Control",

http://tools.ietf.org/html/draft-schaad-eps-smime-00 "Email Policy Service ASN.1 Processing",
http://tools.ietf.org/html/draft-schaad-eps-trust-00 "Email Policy Service Trust Processing"

Draft Charter: sent to IESG and IAB by email
Mailing List: plasma@ietf.org
Mailing List Archive: http://www.ietf.org/mail-archive/web/plasma/
Status: Approved


CDNI - Content Distribution Network Interconnection

Description: There is an emerging requirement for interconnecting content delivery networks (CDNs) so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. This BOF is to discuss the proposed development of IETF standards to facilitate such CDN interconnection. These standards might include protocols for 1) exchange of metadata between CDNs, 2) exchange of transaction logs & monitoring information, 3) exchange of request-routing information, 4) exchange of policies & capabilities, and 5) content management/flushing.
BoF Chairs: Richard Woundy (Richard_Woundy@cable.comcast.com), Francois Le Faucheur (flefauch@cisco.com)
BOF Proponents: Francois Le Faucheur (flefauch@cisco.com), Ben Niven-Jenkins (ben@niven-jenkins.co.uk), Emile Stephan (emile.stephan@orange-ftgroup.com)
People expected: 50
Length of session: 90-120 minutes
Conflicts to avoid: DECADE, NFSv4, STORM, ALTO, TSVWG, TSVAREA, APPSAREA, httpbis
WebEX: Yes
Responsible AD: David Harrington'
Goal: Charter a WG
Agenda: CDNI BOF Agenda IETF 80
Drafts: draft-jenkins-cdni-problem-statement, draft-bertrand-cdni-use-cases, draft-lefaucheur-cdni-requirements draft-jenkins-cdni-names draft-bertrand-cdni-experiments draft-thompson-cdni-atis-scenarios draft-ma-cdni-publisher-use-cases
Draft Charter: CDNI Draft Charter
Mailing List: cdni@ietf.org
Mailing List Archive: http://www.ietf.org/mail-archive/web/cdni/
Status: Approved