Re: Proposed IESG Statement on the Conclusion of Experiments
Ned, On Apr 25, 2012, at 7:31 PM, Ned Freed wrote: I see no value in deallocating code point spaces It depends on the size of the space. Why? Because if you deallocate and reallocate it, there can be conflicts. Perhaps you haven't noticed, but a lot of times people continue to use stuff that IETF considers to be bad ideas, including but not limited to things we called experiments at some point. Perhaps you haven't noticed, but no one was suggesting deallocating and reallocating anything that was in use. Or do you have a different interpretation of if appropriate? How can you possibly determine with any degree of reliability if something you know deployed to some extent is still in use or not? The Internet is a big place. Again, the *only* case where it makes sense to deallocate is if the space is small. In such cases the rewards outweigh the risks. And getting rid of information that people may need to get things to interoperate seems to, you know, kinda go against some of our core principles. Sorry, where did anyone suggest getting rid of any information that people may need to get things to interoperate again? Or do you interpret moving a XML page from a web server into an informational RFC to be getting rid of information? Yes I most certainly did, because that what it amounts to. The instant you move the information to a new place and break the old pointers to it, you have effectively gotten rid of it. I'll admit I find this thread bordering on the surreal with some fascinating kneejerk reactions. What's surreal is your belief that the sorts of actions you're proposing have no consequences. As far as I can tell, the only thing that was proposed was something to encourage documentation of the conclusion of experiments and if appropriate, deprecate any IANA code points allocated for the experiment. Yes, the original statement said deprecate, and I had no problem with it. But this quickly changed to people saying that code points need to be deallocated, which is what I was responding to. Here's a direct quote from an early message on this thread: From my experience at IANA, trying to figure out who to contact to remove a code point gets harder the longer the code points are not being used. Unless the code space is unlimited, I'd argue that you want to deallocate as soon as an experiment is over. remove and deallocate. Not deprecate. And no code space is unlimited. Oh, and you're the one who wrote this. Both of these seem like good things to me. This has somehow been translated into variously: a) a declaration about how research is done b) deletion and/or reallocation of code point spaces that people are using c) killing off successful protocols because they're documented in experimental not standards track rfcs d) violating our core principles e) process for the sake of process f) IANA being a control point for the Internet g) etc. Did I miss a follow-up message from the Inherently Evil Steering Group that proposed these sorts of things? Did I ever say that I was repsonding to the original IESG statement? No, I don't think I ever said that. Anyway, I've made my point, and as PHB said, you've now devolved to stupid tricks to bolster your argument. I'm done. Ned
RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
Stewart, The charter is looking pretty good. I'd like to get on to the next phase, but not with this text: Driven by the requirements and consistent with the gap analysis, the NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. There are two issues with this: Is now the right time to be defining the boundaries on what we might request being chartered next? Framework, requirements and gap analysis drafts are still to be written. If we get to the end and find we need something other than or in addition to a data plan encapsulation or control plane protocol, would we not request it to be chartered? Surely once the work is done. Secondly, as this text got rewritten, it gives a preference for IETF protocols over other protocols even if they are standards. There is a part of the work where an IEEE 802.1 protocol, VDP, may turn out to be suitable. Obviously any IETF protocols that are also suitable should be considered but not to the exclusion of consideration for an IEEE protocol. Presumably there is always a preference for using existing protocol if suitable rather than inventing new. It seems unnecessary to state that - when the time comes, we will debate what is suitable anyway. Therefore, at least Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. should be deleted. Regards, Pat -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, April 25, 2012 2:39 PM To: n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update This version of the NVO3 charter reflects the discussions on the list and comments received as of this afternoon. I propose to take this to the IESG for their second review tomorrow. Stewart == NVO3: Network Virtualization Over Layer 3 Chairs - TBD Area - Routing Area Director - Stewart Bryant INT Area Adviser - TBD OPS Area Adviser - TBD Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Three key requirements needed to support multi-tenancy are: o Traffic isolation, so that a tenant's traffic is not visible to any other tenant, and o Address independence, so that one tenant's addressing scheme does not collide with other tenant's addressing schemes or with addresses used within the data center itself. o Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network. An NVO3 solution (known here as a Data Center Virtual Private Network (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than one hundred thousand physical servers. It thus has good scaling properties from relatively small networks to networks with several million DCVPN endpoints and hundreds of thousands of DCVPNs within a single administrative domain. A DCVPN also supports VM migration between physical servers in a sub-second timeframe. Note that although this charter uses the term VM throughout, NVO3 must also support connectivity to traditional hosts e.g. hosts that do not have hypervisors. NVO3 will consider approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g., VLANs). The NVO3 WG will determine which types of connectivity services are needed by typical DC deployments (for example, IP and/or Ethernet). NVO3 will document the problem statement, the applicability, and an architectural framework for DCVPNs within a data center environment. Within this framework, functional blocks will be defined to allow the dynamic attachment / detachment of VMs to their DCVPN, and the interconnection of elements of the DCVPNs over the underlying physical network. This will support the delivery of packets to the destination VM within the scaling and migration limits described above. Based on this framework, the NVO3 WG will develop requirements for both control plane protocol(s) and data plane encapsulation format(s), and perform a gap analysis of existing candidate mechanisms. In addition to functional and architectural requirements, the NVO3 WG will develop management, operational, maintenance,
RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
I too am uncomfortable with the wording regarding the IETF protocols. It seems that we should be striving to choose the best technical solution regardless of whether its an IETF protocol or that from another SDO. This can, and should, be covered as part of the gap analysis. Also, we should give preference to using existing suitable protocols (IETF or from other SDOs) over development of new protocols. Regards, Joe Pelissier -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Pat Thaler Sent: Wednesday, April 25, 2012 5:55 PM To: Stewart Bryant (stbryant); n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update Stewart, The charter is looking pretty good. I'd like to get on to the next phase, but not with this text: Driven by the requirements and consistent with the gap analysis, the NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. There are two issues with this: Is now the right time to be defining the boundaries on what we might request being chartered next? Framework, requirements and gap analysis drafts are still to be written. If we get to the end and find we need something other than or in addition to a data plan encapsulation or control plane protocol, would we not request it to be chartered? Surely once the work is done. Secondly, as this text got rewritten, it gives a preference for IETF protocols over other protocols even if they are standards. There is a part of the work where an IEEE 802.1 protocol, VDP, may turn out to be suitable. Obviously any IETF protocols that are also suitable should be considered but not to the exclusion of consideration for an IEEE protocol. Presumably there is always a preference for using existing protocol if suitable rather than inventing new. It seems unnecessary to state that - when the time comes, we will debate what is suitable anyway. Therefore, at least Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. should be deleted. Regards, Pat -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, April 25, 2012 2:39 PM To: n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update This version of the NVO3 charter reflects the discussions on the list and comments received as of this afternoon. I propose to take this to the IESG for their second review tomorrow. Stewart == NVO3: Network Virtualization Over Layer 3 Chairs - TBD Area - Routing Area Director - Stewart Bryant INT Area Adviser - TBD OPS Area Adviser - TBD Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Three key requirements needed to support multi-tenancy are: o Traffic isolation, so that a tenant's traffic is not visible to any other tenant, and o Address independence, so that one tenant's addressing scheme does not collide with other tenant's addressing schemes or with addresses used within the data center itself. o Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network. An NVO3 solution (known here as a Data Center Virtual Private Network (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than one hundred thousand physical servers. It thus has good scaling properties from relatively small networks to networks with several million DCVPN endpoints and hundreds of thousands of DCVPNs within a single administrative domain. A DCVPN also supports VM migration between physical servers in a sub-second timeframe. Note that although this charter uses the term VM throughout, NVO3 must also support connectivity to traditional hosts e.g. hosts that do not have hypervisors. NVO3 will consider approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g., VLANs). The NVO3 WG will determine which types of connectivity services are needed by typical DC deployments (for example, IP and/or Ethernet). NVO3 will document the problem statement, the applicability, and an
RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
Joe and Pat, I'm less concerned about this - I think the words if suitable regarding use of existing IETF protocols are sufficient to support choosing the best solution whether it comes from IETF or elsewhere. As Pat notes: when the time comes, we will debate what is suitable anyway. I agree that such a debate is inevitable. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754 -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Joe Pelissier (jopeliss) Sent: Wednesday, April 25, 2012 7:35 PM To: n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25- Apr-2012 update I too am uncomfortable with the wording regarding the IETF protocols. It seems that we should be striving to choose the best technical solution regardless of whether its an IETF protocol or that from another SDO. This can, and should, be covered as part of the gap analysis. Also, we should give preference to using existing suitable protocols (IETF or from other SDOs) over development of new protocols. Regards, Joe Pelissier -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Pat Thaler Sent: Wednesday, April 25, 2012 5:55 PM To: Stewart Bryant (stbryant); n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update Stewart, The charter is looking pretty good. I'd like to get on to the next phase, but not with this text: Driven by the requirements and consistent with the gap analysis, the NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. There are two issues with this: Is now the right time to be defining the boundaries on what we might request being chartered next? Framework, requirements and gap analysis drafts are still to be written. If we get to the end and find we need something other than or in addition to a data plan encapsulation or control plane protocol, would we not request it to be chartered? Surely once the work is done. Secondly, as this text got rewritten, it gives a preference for IETF protocols over other protocols even if they are standards. There is a part of the work where an IEEE 802.1 protocol, VDP, may turn out to be suitable. Obviously any IETF protocols that are also suitable should be considered but not to the exclusion of consideration for an IEEE protocol. Presumably there is always a preference for using existing protocol if suitable rather than inventing new. It seems unnecessary to state that - when the time comes, we will debate what is suitable anyway. Therefore, at least Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. should be deleted. Regards, Pat -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, April 25, 2012 2:39 PM To: n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update This version of the NVO3 charter reflects the discussions on the list and comments received as of this afternoon. I propose to take this to the IESG for their second review tomorrow. Stewart == NVO3: Network Virtualization Over Layer 3 Chairs - TBD Area - Routing Area Director - Stewart Bryant INT Area Adviser - TBD OPS Area Adviser - TBD Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Three key requirements needed to support multi-tenancy are: o Traffic isolation, so that a tenant's traffic is not visible to any other tenant, and o Address independence, so that one tenant's addressing scheme does not collide with other tenant's addressing schemes or with addresses used within the data center itself. o Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network.
RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
Yes -Original Message- From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Wednesday, April 25, 2012 4:59 PM To: Pat Thaler; jopel...@cisco.com Cc: n...@ietf.org; i...@ietf.org; IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update Does deleting IETF in the following sentence: Any documented solutions will use existing IETF protocols if suitable. satisfy your concerns? - Stewart
RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
Works for me also... Thanks! Joe Pelissier -Original Message- From: Pat Thaler [mailto:ptha...@broadcom.com] Sent: Wednesday, April 25, 2012 7:24 PM To: Stewart Bryant (stbryant); Joe Pelissier (jopeliss) Cc: n...@ietf.org; i...@ietf.org; IETF Discussion Subject: RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update Yes -Original Message- From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Wednesday, April 25, 2012 4:59 PM To: Pat Thaler; jopel...@cisco.com Cc: n...@ietf.org; i...@ietf.org; IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update Does deleting IETF in the following sentence: Any documented solutions will use existing IETF protocols if suitable. satisfy your concerns? - Stewart
Re: [MBONED] Last Call: draft-ietf-mboned-64-multicast-address-format-01.txt (IPv4-Embedded IPv6 Multicast Address Format) to Proposed Standard
Hi SM, Thanks a lot for your review, and please see below. On Thu, Apr 26, 2012 at 2:22 AM, SM s...@resistor.net wrote: Hi Med, At 08:05 25-04-2012, mohamed.boucad...@orange.com wrote: Med: Do you mean, cite RFC4291 in addition to the ref to Appendix A.2? Yes, and have Appendix A.2 as informative. Med: Yes, because as listed in Appendix A.2, we wanted to have an a prefix in the ff3x::/32 range. You are using a must. It might be interpreted differently. Maybe adding a quick explanation following it will make it better? Med: We first considered a MUST but we relaxed that required to SHOULD for any future use case which may need to map IPv4 ASM to IPv6 SSM. Does this makes sense to you? Yes. Med: It should be for IANA allocation instead of to IANA. Better? There is no mention of that in the IANA Considerations section. The range is already reserved for SSM destination addresses. Right, that's why we think there is no need to mention that again. Sorry, I'm a little confused. or I misunderstood what you mean? ;-) Cheers, Jacni I am at a lost on that part of the text. I'll defer to you on this. Well, you tried your best. Regards, -sm __**_ MBONED mailing list mbo...@ietf.org https://www.ietf.org/mailman/**listinfo/mbonedhttps://www.ietf.org/mailman/listinfo/mboned
Re: [MBONED] Last Call: draft-ietf-mboned-64-multicast-address-format-01.txt (IPv4-Embedded IPv6 Multicast Address Format) to Proposed Standard
Hi Jacni, Thanks for the feedback. At 08:32 26-04-2012, Jacni Qin wrote: Maybe adding a quick explanation following it will make it better? If it's a requirement, you could use MUST. You are using the RFC 2119 key words in the previous and following bullet points to specify the requirements. Right, that's why we think there is no need to mention that again. Sorry, I'm a little confused. or I misunderstood what you mean? ;-) If one reads the text, it's not clear whether the range is being reserved or not. BTW, Med followed up on this. Regards, -sm
Gen-ART LC Review of draft-ietf-pwe3-static-pw-status-10
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: (Proposed RFC 6478) (was draft-ietf-pwe3-static-pw-status-10) Reviewer: Ben Campbell Review Date: 2012-04-26 IETF LC End Date: 2012-04-30 Note: This draft has previously been approved as RFC 6478, but I understand we are last calling it again due to some material changes in AUTH48. Therefore this is a review of the diff between revision 10 and the text at http://www.rfc-editor.org/authors/rfc6478.txt Summary: The edited text is essentially ready for publication, but I have a couple of minor issues that might should be considered first. Major issues: None Minor issues: -- 5.3, last paragraph: The last sentence changed from a non-normative statement to This SHOULD cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. Is that really intended as a normative statement, or a statement of fact? I suspect it's the latter, but if the former, then it should be stated more of the form If the sending PE receives ... it SHOULD stop ... -- IANA considerations: Maybe I missed it, but I don't see a registration policy for adding things to the new registry. This wasn't an AUTH48 change, but it should probably be there.
Weekly posting summary for ietf@ietf.org
Total of messages in the last 7 days. script run at: Fri Apr 27 00:53:02 EDT 2012 Messages | Bytes| Who +--++--+ +--++--+
Last Call: draft-ietf-codec-opus-12.txt (Definition of the Opus Audio Codec) to Proposed Standard
The IESG has received a request from the Internet Wideband Audio Codec WG (codec) to consider the following document: - 'Definition of the Opus Audio Codec' draft-ietf-codec-opus-12.txt as a Proposed Standard 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 2012-05-10. 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 defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-codec-opus/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-codec-opus/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1712/ http://datatracker.ietf.org/ipr/1602/ http://datatracker.ietf.org/ipr/1445/ http://datatracker.ietf.org/ipr/1446/ http://datatracker.ietf.org/ipr/1447/ http://datatracker.ietf.org/ipr/1741/ http://datatracker.ietf.org/ipr/1670/ http://datatracker.ietf.org/ipr/1520/ http://datatracker.ietf.org/ipr/1524/ http://datatracker.ietf.org/ipr/1525/ http://datatracker.ietf.org/ipr/1526/
CORRECTION: WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis)
An incorrect version of the new Hypertext Transfer Protocol Bis (httpbis) working group charter was sent to the Secretariat and posted on 19 March 2012. This version correctly reflects what the IESG approved. For additional information, please contact the Area Directors or the working group Chairs. Hypertext Transfer Protocol Bis (httpbis) - Charter Last Modified: 2012-04-13 Current Status: Active Working Group Chair(s): Mark Nottingham m...@mnot.net Applications Area Director(s): Barry Leiba barryle...@computer.org Pete Resnick presn...@qualcomm.com Applications Area Advisor: Barry Leiba barryle...@computer.org Mailing Lists: General Discussion:ietf-http...@w3.org To Subscribe: ietf-http-wg-requ...@w3.org In Body: subscribe Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group: This Working Group is charged with maintaining and developing the core specifications for HTTP. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 (HTTP/1.1) and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP/1.1 * A document that specifies HTTP/2.0, an improved binding of HTTP's semantics to an underlying transport. HTTP/1.1 HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments HTTP/2.0 There is emerging implementation experience and interest in a protocol that retains the semantics of HTTP, without the legacy of HTTP/1.x message framing and syntax, which have been identified as hampering performance and encouraging misuse of the underlying transport. As such, there is an opportunity to create a new major (non-wire-compatible) version of HTTP. To do this, the Working Group will solicit candidates for this work from the community, to be submitted as Internet-Drafts. Expected focus areas for candidates include: * Significantly improved perceived performance in common use cases (e.g., browsers, mobile) * More efficient use of network resources; in particular, reducing the need to use multiple TCP connections * Ability to be deployed on today's Internet, using IPv4 and IPv6, in the presence of NATs * Maintaining HTTP's ease of deployment * Reflecting modern security requirements and practices With regard to security requirements, in the initial phase of work on HTTP/2.0, new proposals for authentication schemes can be made. The WG will have a a goal of choosing at least one scheme that is better than those available for HTTP/1.x. However, the WG might select zero schemes. In addition, non-selected schemes might be discussed with the IETF Security Area for further work there. Although proposals are not required to meet all of these goals, it is expected that the resulting work (if undertaken) will be chartered to meet them (and therefore, selecting one that meets the majority of them as a starting point is in everyone's interest). The Working Group will then select a starting point for the new work based upon the following criteria: * Compatibility with HTTP/1.1 semantics; i.e., it must be possible to pass through a HTTP/1.1 message with reasonable fidelity * Broad implementer interest (e.g., from Web browsers, back-end or web api uses of HTTP, servers, intermediaries, CDNs, etc.) Changes to the existing semantics of HTTP are out of scope in order to preserve the meaning of messages that might cross a 1.1 -- 2.0 -- 1.1 request chain.
