WG Review: Content Delivery Networks Interconnection (cdni)
A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, June 21, 2011. Content Delivery Networks Interconnection (cdni) Current Status: Proposed Working Group Last updated: 2011-05-27 Chairs: TBD Transport Area Directors: Wesley Eddy w...@mti-systems.com David Harrington ietf...@comcast.net Transport Area Advisor: David Harrington ietf...@comcast.net Mailing lists: Address: c...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: http://www.ietf.org/mail-archive/web/cdni/ Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A problem statement document providing a description of the problem and a common terminology. - A use case document describing scenarios for usage and applications of the CDNI solution and protocols. - A framework document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a threat analysis discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A requirements document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the CDNI request-routing interface. This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the CDNI metadata interface. This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the CDNI logging interface. This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the CDNI control interface.
WG Action: IPv6 Site Renumbering (6renum)
A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. IPv6 Site Renumbering (6renum) --- Current Status: Active Working Group Chair: Tim Chown t...@ecs.soton.ac.uk Operations and Management Area Directors: Ron Bonica rbon...@juniper.net Dan Romascanu droma...@avaya.com Operations and Management Area Advisor: Ron Bonica rbon...@juniper.net Mailing list Address: re...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/renum Archive: http://www.ietf.org/mail-archive/web/renum/ Description --- As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is currently viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. As that RFC describes, there are triggers that mean some cases of renumbering are unavoidable, so it should be considered a given that a site may need partial or complete renumbering at some stage. It is thus important to implement and deploy techniques that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes universally deployed, renumbering can be viewed as a more routine event. This includes consideration of how the initial assignment and subsequent management of address information is performed, as this will affect future renumbering operations. If IPv6 site renumbering continues to be considered difficult, network managers will turn to PI addressing for IPv6 to attempt to minimise the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. Renumbering, or partial renumbering, can be complicated in an enterprise site where a short prefix is divided into subnets with longer prefixes. Aggregation, synchronisation, coordination, etc., need to be carefully managed, and the use of manually inserted address literals minimised. Other factors such as applications binding long-term to low level IP addresses may add constraints to what can be realistically achieved, but identifying and documenting such factors is a useful objective. In some scenarios, consideration may also need to be made for 'flag day' renumbering (in contrast to the procedure described in RFC4192). The task of the 6RENUM working group is to document existing renumbering practices for enterprise site networks and to identify specific renumbering problems or 'gaps' in the context of partial or site-wide renumbering. Completion of these tasks should provide a basis for future work to identify and develop point solutions or system solutions to address those problems or to stimulate such development in other working groups as appropriate. 6RENUM is chartered to perform an analysis of IPv6 site renumbering. If the analysis leads to conclusions that are also applicable to IPv4 that will be an advantage, but it is not an objective of the WG to make its outputs more widely available than IPv6. Similarly the WG is targeting enterprise networks, but the analysis may also be applicable to SOHO or other (e.g. ad-hoc) scenarios. It may be that for site renumbering to become more routine, a systematic address management approach will be required. By documenting current practices and undertaking a gap analysis, we should become better informed of the requirements of such an approach. Post-analysis rechartering may lead to further work in this area. RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work. Goals/deliverables -- The goals of the 6RENUM working group are: 1. To undertake scenario descriptions, including documentation of current capability inventories and existing BCPs, for enterprise networks, including managed and unmanaged elements. These texts should contribute towards a gap analysis and provide an agreed basis for subsequent WG rechartering towards development of solutions (which may be more appropriate for other WGs to undertake) and improved practices. Operator input will be of high value for this text. 2. To perform a gap analysis for renumbering practices, to identify generic issues for network design, network management, address management and renumbering operations. The methodology for the WG will be to begin building the enterprise scenario description while in parallel constructing an initial gap analysis drawing on existing work in (at least) RFC4192 and RFC5887. As the scenario text hardens, its contributions will be incorporated into the more detailed gap analysis, which can be published once the scenario text is completed. The deliverables are thus the scenario and gap analysis texts. The following topics are out of scope for the working group:
WG Action: Protocol to Access White Space Databases (paws)
A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. Protocol to Access White Space Databases (paws) Current Status: Active Working Group Chairs: Gabor Bajko gabor.ba...@nokia.com Brian Rosen brian.ro...@neustar.biz Applications Area Directors: Pete Resnick presn...@qualcomm.com Peter Saint-Andre stpe...@stpeter.im Applications Area Advisor: Peter Saint-Andre stpe...@stpeter.im Mailing lists: General Discussion: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called white space and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help unlock existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated by information provided by the appropriate spectrum regulation bodies and by spectrum licensees. 2. A radio device that wishes to query such a database. Typically, the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location and the current time to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of currently available white space using a well-defined format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize query and response formats to be carried over the database access method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. By standardize is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will
WG Action: RECHARTER: Web Authorization Protocol Working Group (oauth)
The Web Authorization Protocol Working Group (oauth) in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Web Authorization Protocol Working Group (oauth) --- Current Status: Active Working Group Chairs: Barry Leiba barryle...@computer.org Hannes Tschofenig hannes.tschofe...@gmx.net Blaine Cook rom...@gmail.com Security Area Directors: Stephen Farrell stephen.farr...@cs.tcd.ie Sean Turner turn...@ieca.com Security Area Advisor: Stephen Farrell stephen.farr...@cs.tcd.ie Technical Advisor: Peter Saint-Andre stpe...@stpeter.im Mailing List: Address: oa...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/ Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account. OAuth encompasses * a mechanism for a user to authorize issuance of credentials that a third party can use to access resources on the user's behalf and * a mechanism for using the issued credentials to authenticate HTTP requests. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). The working group has since been developing OAuth 2.0, a standards-track version that will reflect IETF consensus. Version 2.0 will consider the implementation experience with version 1.0, a discovered security vulnerability (session fixation attack), the use cases and functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will * improve the terminology used, * consider broader use cases, * embody good security practices, * improve interoperability, and * provide guidelines for extensibility. The working group will develop authentication schemes for peers/servers taking part in OAuth (accessing protected resources). This includes * an HMAC-based authentication mechanism This document aims to provide a general purpose MAC authentication scheme that can be used both with OAuth 2.0 but also with other use cases. The WG will work with the security and applications area directors to ensure that this work gets appropriate review, e.g. via additional last calls in other relevant working groups such as HTTPBIS, * a specification for access protected by Transport Layer Security (bearer tokens), * an extension to OAuth 2.0 to allow access tokens to be requested when a client is in possession of a SAML assertion. A separate informational description will be produced to provide additional security analysis for audiences beyond the community of protocol implementers. Milestones will be added for the later items after the near-term work has been completed. Goals and Milestones May 2011Submit 'HTTP Authentication: MAC Authentication' as a working group item May 2011Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Jul 2011Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard Jul 2011Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Aug 2011Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Oct 2011Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0' to the IESG for consideration as a Proposed Standard Oct 2011Re-chartering working group ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The A+P Approach to the IPv4 Address Shortage' to Experimental RFC (draft-ymbk-aplusp-10.txt)
The IESG has approved the following document: - 'The A+P Approach to the IPv4 Address Shortage' (draft-ymbk-aplusp-10.txt) as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ymbk-aplusp/ Technical Summary We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4-world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This draft proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional end point identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., CPE, mobile phones), each with its assigned port-range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process - not some smart boxes in the core. Working Group Summary This document is not the product of a working group. Document Quality - Are there existing implementations of the protocol? Yes, one (ISC AFTR A+P support), but without dynamic port allocations and no stateless support. Other implementations to follow, one of obstacles is current status (draft). - Have a significant number of vendors indicated their plan to implement the specification? Iskratel, possibly Cisco and Juniper. - Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? All last version thorough reviewers are now among authors: Mohammed Boucadair (FT) Reinaldo Penno (Juniper) Personnel Ron Bonica is document shepherd ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'SIP (Session Initiation Protocol) Usage of the Offer/Answer Model' to Informational RFC (draft-ietf-sipping-sip-offeranswer-18.txt)
The IESG has approved the following document: - 'SIP (Session Initiation Protocol) Usage of the Offer/Answer Model' (draft-ietf-sipping-sip-offeranswer-18.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipping-sip-offeranswer/ Technical Summary The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. Also, this document tries to incorporate the results of the discussions on the controversial issues to avoid repeating the same discussions later. This document does not make normative changes. Rather, it recommends how to use the existing standards to best effect. Working Group Summary This document began in the SIPPING working group, which reached consensus to request publication of an earlier version. After IETF Last Call, the community identified several significant changes and additions to the document. There has been discussion around whether the document should be PS or BCP instead of informational, with the consensus being that this document should be published as is to capture discussion to date and inform any future efforts to update the various proposed standards it references. Document Quality This document has received detailed revew from Christer Holmberg, Rajeev Seth, Nataraju A B, Byron Campen, Jonathan Rosenberg, Gonzalo Camarillo, Yang Gao, and Ben Campbell. Personnel Mary Barnes is the document's shepherd, Robert Sparks is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
New Non-WG Mailing List: webapps -- Impact of web technologies on the future of applications development
A new IETF non-working group email list has been created. List address: weba...@ietf.org Archive: http://www.ietf.org/mail-archive/web/webapps/ To subscribe: https://www.ietf.org/mailman/listinfo/webapps Description: Post-IETF-80 discussion of the impact of .js, HTML5 and related work on the future of applications development. For additional information, please contact the list administrators. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-fecframe-framework-15.txt (Forward Error Correction (FEC) Framework) to Proposed Standard
The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'Forward Error Correction (FEC) Framework' draft-ietf-fecframe-framework-15.txt as a Proposed Standard The IESG reviewed this draft and requested substantial changes. This is a second Last Call, running for one week, to ensure the community has an opportunity to review the changes. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-06-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Virtual Router Redundancy Protocol (vrrp)
The Virtual Router Redundancy Protocol (vrrp) working group in the Routing Area has concluded. The IESG contact persons are Adrian Farrel and Stewart Bryant. The mailing list will remain active. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
