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

Timeframe IETF 86 (Orlando)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 17:00 PT Monday, January 28, 2013 (01:00 UTC Tuesday, January 29). 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 February 7.

Applications

Aggregated Service Discovery (aggsrv)

Status: Requested

  • Description: Standardization of a simplified and efficient means for aggregated service discovery (WG-forming).
  • Responsible AD: Pete Resnick
  • BoF Chairs: Peter Saint-Andre
  • Number of people expected to attend: 100
  • Length of session: 1 hour
  • Conflicts to avoid: All App Area sessions
  • WebEX, Meetecho: No

Javascript Object Notation (json)

Status: Requested

  • Description: Move JSON spec (RFC 4627) to Standards Track; handle other JSON-related work in progress (WG-forming).
  • Responsible AD: Barry Leiba
  • BoF Chairs: Joe Hildebrand
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid: All App Area sessions
  • WebEX, Meetecho: No
  • I-Ds: (see bottom of charter draft)

General

History of the Internet (HISTORY)

  • Computer networking, including the Internet, the Web, and mobile technology, is one of the most profound and exciting technologies of our time. It has affected the lives of billions, and its use continues to expand around the globe. It is important to record how such a thing came about, what it is, who developed it, how it spread, how it is used, its impact on society – in short, its history. The online world is now so vast that recording what has happened in it and why is not a small task. Many agree it could use collaboration and coordination. Should an IETF WG address how best to preserve the history of networking? The WG could start by identifying legitimate collectors of networking artifacts and archives around the world; then come up with some guidelines in an Information RFC for contributions. This activity might also develop a methodology for pioneers, emerging developers, organizations, and countries using networking to preserve key parts of its history.
  • The responsible Area Director (AD) is Russ Housley.
  • BoF Chair is Marc Weber from Computer History Museum.
  • Expected attendance is 75 people.
  • Length of session is 1 hour.
  • Avoid conflicts with all other BOFs. Please schedule for Monday.
  • Does not require WebEx.
  • Does not require Meetecho.
  • Inspiration: http://www.computerhistory.org/collections/accession/102706170
  • I-D: None.
  • Mail list: None.

Proposed Update IPR Policy (IPRbis)

IAB-sponsored Discussion of WCIT (IAB-WCIT)

  • What happened at the World Conference on International Telecommunications (WCIT)? Should the IAB or the IETF take any action on any of the issues that were surfaced at WCIT?
  • The responsible Area Director (AD) is Russ Housley.
  • BoF Chairs are Ross Callon and Joel Halpern.
  • Expected attendance is 200 people.
  • Length of session is 1 hour.
  • Avoid conflicts with all other BOFs, OPSWG, DISPATCH, WIERDS, MPLS, LISP, and KARP. Please schedule for Thursday.
  • Does not require WebEx.
  • Does not require Meetecho.
Information sharing ...
 (1) what was WCIT
 (2) what happened
 (3) what did not happen

Short open mic that is focused on one question ...
 (4) does WCIT affect any of the work in the IAB or IETF?
   -- OR --
   should the IAB or the IETF take any action on any of the issues that were surfaced at WCIT?

Internet

(mdnsext BoF request has been retracted)

Operations and Management

Web PKI OPS (WPKOPS)

  • This is a place-holder BoF request for WPKOPS which is in the process of being chartered as a WG at the moment.
  • The draft charter can be found at https://datatracker.ietf.org/doc/charter-ietf-wpkops/
  • The responsible AD is Ron Bonica.
  • Chairs have not yet been appointed.
  • Attendance c.50
  • Session length 2 hours
  • 1st level conflicts to avoid: opsawg, websec, SEC area, OPSEC, V6OPS, MBONED, BMWG, 6renum, GROW
  • 2nd level conflicts to avoid: httpbis
  • No WebEX
  • No Meetecho

Large-Scale Measurement of Broadband Performance (LMAP)

Description

Measuring broadband service on a large scale requires standardization of the logical architecture and describing the key requirements for protocols to coordinate interactions between the components.

Proposed WG Charter Proposed LMAP Charter

Measuring broadband service on a large scale is important for network diagnostics by providers and users, as well for public policy. Large-scale measurement efforts that exist today often use proprietary, custom-designed mechanisms to coordinate the Measurement Agents (MAs) on user networks, the communications between Measurement Agents and measurement Controllers, and the uploading of results to measurement Collectors. Standardizing these mechanisms will make it possible to build interoperable measurement capabilities, both active and passive, into home and enterprise edge routers, personal computers, mobile devices and other edge devices that are offered and controlled by disparate entities across residential and small-enterprise networks, whether wired or wireless. Standards will help these capabilities become more pervasive, manageable and directly comparable.

The Large-Scale Measurement of Broadband Performance Architectures and Protocols (LMAP) working group is chartered to develop data models and protocols that allow a measurement Controller to instruct Measurement Agents about what performance metrics they measure, when to measure them, and how to report the measurement results. The primary outputs of the working group are the data models that define the tests and reports, and protocols for securely delivering these data models to /from the MAs. The work of the group is currently scoped under the following assumption: the measurement system is under the direction of a single organisation that is responsible both for the data and the user experience. Given the novelty of large-scale measurement efforts, the expectation is that inter-organization coordination is an out-of-band consideration.

Many measurement aspects are already within the charter of IPPM and are therefore out of scope for LMAP. These include standardised definitions of performance metrics and a registry of frequently-used metrics, so that they can be efficiently measured in a consistent fashion.

Neither the definition of the tests, nor the preparation and analysis of results falls within the remit of LMAP. The preparation of the results will depend greatly on the party collecting the data and the business or market problem they are trying to solve. While there is an obvious need to be able to benchmark the performance of different products and network operators, statistics averaged over multiple MAs should be defined elsewhere, such as IPPM. The measurement framework must, of course, be able to operate the required tests on the required number of MAs for the required schedules to enable such benchmarks.

Another area that is considered out of scope is the management systems to manage the devices on which tests are conducted, or to report line or contract parameters. While such parameters can be used to decide which tests to run, or to interpret the results (for example assigning the correct product categorisation), these parameters are already gathered and stored by existing OSS. Deciding which tests to run is clearly a business decision and is out of scope along with the processing of test results. The decision of which tests to run on a single device can be made without further conversation with the device since the device management already knows the device capabilities and the existing test schedule. Broadband Forum standards allow a limited capability to run on-demand delay and throughput tests on home gateways. LMAP develops standards that allow multi-vendor MAs which run a flexible set of scheduled tests, with mass-scale reporting.

LMAP is chartered to produce the following work items:

  1. Framework. This provides common terminology, motivating use cases, and justifies the simplifying architectural assumptions
  1. Data model that defines how the Controller instructs an MA about a test. It includes the metric to be measured and values for its parameters such as the test server against which the MA runs the test and whether there are any ‘conditions’ (for example, only make the measurement when there is no user traffic). It also includes the schedule (when the test should be run) and how the results should be reported (where to and when).
  1. Data model that defines the report that the MA sends to the Collector. It includes what metric was measured and when, the actual result, and perhaps ‘metadata’ such a mobile’s location. Results will typically be bunched together but a one-off test may be reported immediately.
  1. The application level protocol for the (secure) delivery of the test data model. This is a simple instruction – response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or Netconf).
  1. Similarly, the application level protocol for the (secure) delivery of the report data model.

Goals and Milestones

Dec 2013: Framework, including terminology and use cases (Informational)
July 2014: Data model for test (Standards track)
July 2014: Data model for report (Standards track)
Dec 2014: Application level protocol for delivery of test data model (Standards track)
Dec 2014: Application level protocol for delivery of report data model (Standards track)

Existing docs:
http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements[[BR]] http://tools.ietf.org/html/draft-linsner-lmap-use-cases[[BR]] http://tools.ietf.org/html/draft-morton-ippm-lmap-path-00[[BR]] framework (to be submitted)

RAI

No BoFs requested for IETF86

Routing

Interface To the Routing System (I2RS)

  • This is a place-holder BoF request for I2RS which is in the process of being chartered as a WG at the moment.
  • The draft charter can be found at http://datatracker.ietf.org/doc/charter-ietf-i2rs/
  • The responsible AD is Adrian Farrel.
  • Chairs have not yet been appointed.
  • Attendance c.120
  • Session length 2.5 hours
  • 1st level conflicts to avoid: Routing Area meeting, Ops Area meeting, ForCES, Netmod, Netconf, Opsawg, Rtgwg, MPLS, OSPF, ISIS, PCE, IDR, Grow, SDNRG
  • 2nd level conflicts to avoid: Sidr, PIM, L2vpn, L3vpn, Cdni, Alto
  • Prefer NOT Monday
  • No WebEX
  • No Meetecho

Security

Security Automation and Continuous Monitoring (SACM)

  • Status: Requested.
  • Type: WG forming (2nd attempt).
  • Responsible AD: Sean Turner.
  • BOF Chairs: Kathleen Moriarty and Dan Romascanu.
  • Attendance: 80
  • Session length 90 minutes
  • Conflicts to avoid: SEC area WGs especially MILE as well as XRBLOCK, EMAN, OPSAWG, NETMOD, NETCONF, APPSAWG, SCIM
  • Does it require WebEX? No
  • Does it require Meetecho? Yes
  • Mailing list: ​sacm@ietf.org
  • List archive: ​https://www.ietf.org/mailman/listinfo/sacm

Description

Securing information and the systems that store, process, and transmit that information is a challenging task for organizations of all sizes, and many security practitioners spend most of their time on manual processes relegating them to ineffectiveness. The key to escaping this rut is security automation to collect, verify, and update system configurations with the ability to prioritize risk based on timely information about threats. This working group will develop security automation protocols and data format standards in support of information security processes and practices. These standards will help security practitioners to be more effective by automating routine tasks related to client and server security freeing them to focus on more advanced tasks. The initial focus of this work is to address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209).

Proposed WG Charter

From: https://www.ietf.org/mail-archive/web/sacm/current/msg00931.html, but included here to save you some clicks.

Name: Security Automation and Continuous Monitoring (SACM)
AREA: Security

Chairs:
TBD
TBD

Security Area Directors:
     Stephen Farrell <stephen.farrell at cs.tcd.ie>
     Sean Turner <turners at ieca.com>

Security Area Advisor:
     Sean Turner <turners at ieca.com>

Mailing Lists:
     General Discussion: sacm at ietf.org
     To Subscribe:       http://www.ietf.org/mailman/listinfo/sacm
     Archive:            http://www.ietf.org/mail-archive/web/sacm

Description of Working Group

Securing information and the systems that store, process, and transmit
that information is a challenging task for organizations of all sizes,
and many security practitioners spend most of their time on manual
processes relegating them to ineffectiveness. The key to escaping this
rut is security automation to collect, verify, and update system
configurations with the ability to prioritize risk based on timely
information about threats. This working group will develop security
automation protocols and data format standards in support of
information security processes and practices. These standards will
help security practitioners to be more effective by automating routine
tasks related to client and server security freeing them to focus on
more advanced tasks. The initial focus of this work is to address
enterprise use cases pertaining to the assessment of endpoint posture
(using the definitions of Endpoint and Posture from RFC 5209).

The working group will, whenever reasonable and possible, reuse
existing protocols and mechanisms. Of particular interest to this
working group are the security automation specifications supporting
asset, change, configuration, and vulnerability management.

There are multiple categories of problems in the security automation
realm: enabling interoperable data exchanges through standardized
protocols, defining expressions for particular domain concepts
(i.e. data formats), establishing a standards-based foundation
supporting the curation and exchange of security automation content
collections in content repositories, and enabling interoperability
through the development and use of standard interfaces and
communication protocols. Content based on rich and extensible data
standards and protocols will provide the authoritative instructions
needed by data-driven tools to enable the automated collection of
configuration and vulnerability data pertaining to enterprise
assets. Information produced by these tools will provide accurate and
timely situational awareness in support of organizational decision
making.

The data exchange protocols will need to support several exchange
types including requesting assessments and reporting on assessment
results. Exchanging information across organizational boundaries will
not be within scope for this effort at this time.

This working group will provide solutions to these categories of
problems and the main areas of focus for this working group are
described as follows:

1. A set of standards to enable assessment of endpoint posture.
   This area of focus provides for necessary language and data
   format specifications.

2. A set of standards for interacting with repositories of content
   related to assessment of endpoint posture.

This working group will achieve the following milestones:

- An Informational document on Use Cases and Requirements
- An Informational document on SACM Architecture
- A Standards Track document to define a protocol for interacting
  with content repositories
- Standards Track documents specifying communication protocols and
  data formats used for assessment of endpoint posture

After these work items have been submitted to and approved by
the IESG, the WG will recharter or close.

Documents

Hypertext Transmission Protocol Authentication (httpauth)

  • Status: Requested.
  • Type: This is really just a placeholder. Holding another BOF probably won't lead to us finding out any new information so the charter's been floated and if there's still interest, then I'd propose forming the WG before IETF 86.
  • Responsible AD: Sean Turner.
  • BOF Chairs: N/A.
  • Attendance: 80
  • Session length 90 minutes
  • Conflicts to avoid: SEC area, Barry's APP WGs, and rtcweb
  • Does it require WebEX? No
  • Does it require Meetecho? No
  • Mailing list: ​http-auth@ietf.org
  • List archive: ​https://www.ietf.org/mailman/listinfo/http-auth

Description The httpauth WG will be a short-lived working group that will document a small number of HTTP user authentication schemes that might offer security benefits, and that could, following experimentation, be widely adopted as standards-track schemes for HTTP user authentication. Each of the RFCs produced should include a description of when it is appropriate to be used, e.g. via a use-case or other distinguishing characteristics.

Proposed WG Charter

From: https://www.ietf.org/mail-archive/web/http-auth/current/msg01187.html, but included here to save you some clicks.

Name: HyperText Transmission Protocol Authentication (HTTPAUTH)
AREA: Security

Chairs:
TBD
TBD

Security Area Directors:
     Stephen Farrell <stephen.farrell at cs.tcd.ie>
     Sean Turner <turners at ieca.com>

Security Area Advisor:
     Sean Turner <turners at ieca.com>

Mailing Lists:
     General Discussion: http-auth at ietf.org
     To Subscribe:       http://www.ietf.org/mailman/listinfo/http-auth
     Archive:            http://www.ietf.org/mail-archive/web/http-auth

Description of Working Group

HTTP authentication is currently used for user authentication by few
web sites. Form-based or "web" authentication is much more commonly
used. Only the former is in scope here, the latter is out of scope. 

The httpauth WG will be a short-lived working group that will document
a small number of HTTP user authentication schemes that might offer
security benefits, and that could, following experimentation, be
widely adopted as standards-track schemes for HTTP user
authentication. Each of the RFCs produced should include a description
of when it is appropriate to be used, e.g. via a use-case or other
distinguishing characteristics.

All schemes to be developed in the httpauth WG must be usable with the
existing HTTP authentication framework, or with evolutions of that
framework as developed in the httpbis WG. That is, the evolution of
the HTTP authentication framework is to be done in the httpbis WG and
not in the httpauth WG. 

The httpauth WG will work closely with the httpbis WG to ensure that
the outcomes from the httpauth WG do not conflict with work done
elsewhere.

The starting points for work will be:

- draft-williams-http-rest-auth 
- draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension
- draft-farrell-httpbis-hoba
- draft-montenegro-httpbis-multilegged-auth
- draft-melnikov-httpbis-scram-auth

In addition, the WG will aim to get rough consensus on two drafts that
will obsolete the basic and digest schemes defined in RFC 2617 taking
into account errata on that specification. 

For the digest scheme, "more modern" algorithm agility and
internationalisation support will be developed as a standards-track
RFC. The starting point for this will be
draft-ahrens-httpbis-digest-auth-update, but the WG is not precluded
from e.g. adding a Diffie-Hellman exchange to this method.

For the basic scheme, no technical changes are envisaged other than to
handle i18n of usernames and passwords, the goal will simply be to
improve the documentation of the scheme to allow obsoleting RFC 2617
which has some significant flaws when looked back at 13 years later.

Other than the documents that aim to obsolete RFC 2617, the rest of
the WG output will be a set of informational or experimental RFCs.

Other than obsoleting RFC 2617 developing standards track solutions is
out of scope as none of the proposals are expected to be sufficiently
widely deployed to warrant that status before the WG closes. 

The WG is not required to merge all proposals into one. The goal is
not that participants reach rough consensus on every proposal, but
rather to review and improve proposals and to quickly produce stable
specifications and then close.

It is expected that the market/community will select which if any of
the RFCs developed might be worth progressing on the standards-track
at a later date, in a different WG.

Adoption of additional work items is not expected and will require a
re-charter.

The following are explicitly out of scope:

- changes to TLS
- changes to HTTP, however, if some change is proposed
  that is clearly supported by the httpbis WG then that would
  be fine, for example, one might envisage that a new HTTP header
  field might be acceptable if both this and the httpbis wg
  had rough consensus for the addition of that header field,
  albeit that working solely within the existing authentication
  framework is preferable to defining new header fields
- definition of authentication mechanisms that do not work with
  the HTTP authentication framework
- authentication schemes that distinguish between devices and humans 
  or for components of web services, and that cannot be sensibly used
  for humans, for example device state authentication such as done 
  by the NEA wg is out of scope
- "web" authentication that is not HTTP authentication

Milestones:

- TBD

Transport