My statement to the press about DNSSEC
Last night by video link I participated in a press conference that was arranged by ICANN. I was part of a panel; the rest of the people were in Las Vegas at the BlackHat conference. Each panel member gave a 3 minute statement, and then the panel responded to questions from the reporters. I thought it appropriate to share my opening statement with the whole IETF community. Russ - - - - - - - - - - RUSS HOUSLEY COMMENTS DNSSEC NEWS CONFERENCE 28 July 2010 Thanks, Rod. I'm sorry I can't be with you in person today. I am not there because I am in the Netherlands at the 78th meeting of the Internet Engineering Task Force. I'm here with almost 1200 of the leading Internet engineers and researchers from around the world. As Rod mentioned, I'm Chair of the IETF, which is a global community with the mission of making the Internet work better. For nearly 35 years, using an open and transparent process, we have gathered thousands of individuals from around the world to develop a wide range of Internet-related protocols. That is, the technical specifications that allow the various devices that comprise the Internet to talk with each other using a common language to provide the services that everyone has come to expect and enjoy from the Internet. The Domain Name System, or DNS, is one of those protocols - one with special significance. It is used by billions of Internet users as they send email, browse the Web, and use many other applications every day. DNS can be thought of in three different ways: first, a set of protocols, second, a service, and a finally, as a global infrastructure. For the past 27 years, the work of the IETF community has defined the protocols that make up the Domain Name System. This includes the extensions that make up the DNS Security, or DNSSEC. DNSSEC is the result of an incredible amount of careful work by IETF participants. Work began over 17 years ago, with over 200 individuals contributing along the way. While the whole DNSSEC solution is difficult to explain succinctly, DNSSEC can be thought of as a tamper-proof package for domain name information. I am extremely pleased to help celebrate the protocol specifications, implementations, and the deployment of this core Internet infrastructure. I applaud the huge amount of work done by many other organizations -- including several represented here on the panel. Their cooperative efforts made the DNSSEC deployment happen. The fact that this significant event passed without disruption and went unnoticed by most Internet users is testament to the cooperation and care taken by all involved. I know that the whole Internet engineering community is excited about this significant achievement. In fact, at the meeting here in Maastricht earlier today we took a short pause in the technical discussions to toast the signing of the DNS root zone. I assure you this is not a common occurrence at a meeting of engineers; it clearly shows of the significance of this event. So, thanks again for using the Internet to include me on this panel. I am very pleased to convey the enthusiasm of the Internet Engineering Task Force for the progress so far in the deployment of DNSSEC. We are meeting right now to work on other protocols that will enable the Internet to continue to grow and evolve and become more secure. Thank you. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Internet upgraded to foil cyber crooks
http://news.yahoo.com/s/afp/20100729/tc_afp/usitinternetsoftwarecrimeicannblackhat Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet upgraded to foil cyber crooks
http://news.yahoo.com/s/afp/20100729/tc_afp/usitinternetsoftwarecrimeicannblackhat I guess the next report after a noticeable increase of IPv6 deployment will be something like We made the Internet larger ... Cheers ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Ad Hoc BOFs
The IETF list is often a place for rants and raves. I have a concern that I want to raise, but I also want to be constructive about it. I'm hoping my colleagues will play ball with that. I am really happy to see the interest and conversation that has been happening at IETF-77 and IETF-78 regarding potential new work and topics of interest, aka Bar BOFs. The infusion of new work and discussions of topics of interest is a good thing. I want to talk about how it is done. I have a concern. The concern is in essence a lack of regard for people's health and time. For me, IETF-78 started on Sunday afternoon and has proceeded until now (9:33 Thursday evening) with seven breaks - a social event, a private social event, nights in which I have gone to my hotel and collapsed for five or six hours, and this afternoon when I did the same. The entire remaining time has been consumed in meetings - meals, IETF WG and BOF meetings, receptions and plenaries, and various ad hoc conversations. Many of these have been so-called Bar BOFs. By the way, I am far from alone. At IETF-77, people complained that leadership (IESG/IAB/etc) didn't show up at their Bar BOFs. For those people, the IETF is a far busier meeting. When I was IETF Chair, I scheduled potty breaks, and I couldn't cross a room to get a glass of wine or cup of coffee without being stopped several times by someone who needed to chat with me. Our leaders are generally happy to be helpful any way they can, but they deserve our respect for the incredible time and work commitment that they make. Let me explain what a Bar BOF is, and what it is not. Our formal BOFs are scheduled with an AD, and are generally for formalizing a charter. The assumption is that a prior ad hoc process, usually on a mailing list or via telephone or conferencing systems has happened, and a work item has matured to the point that we have interested people, proto-specifications or at least problem statements, and so on. The initiation point of that is often-but-not-always a handful of people talking over a meal or in a bar on a topic, often having convened mere moments before. Sketches might be drawn on napkins, and people that are hungry or thirsty have a waiter/waitress at hand to deal with that. A Bar BOF, as such small gatherings are called, is *not* a full-blown meeting of perhaps hundreds of people placed at a mealtime but in a place that prevents them from eating. It does not require powerpoint, and is not a catered event. It is not ten minutes stolen from some other subject. Key concept: we respect each other and each other's time, and so we meet in a place that has food and drink, and we have an intimate conversation among people who will be interested to carry on some work item. Another way that conversations that lead to eventual working group formation are initiated tends to be ad hoc meetings. These might be similarly carried out over dinner, but they usually happen at a time that the participants have no other plan - the key attendees are not in any other meeting and so are free, or perhaps they planned in advance to meet Sunday afternoon or on the Saturday following. Meetings of this type may happen at IETF meetings, but they are planned weeks in advance, soon after the IETF agenda is finalized. If IETF rooms are available, so be it; often, companies that want to have these meetings provide a room of their own. BOFs are necessary. Ad Hoc meetings happen, although they can be a pain to include in one's schedule. Bar BOFs, the kind that happen in bars and are a small number of co-conspirators, are part of the fabric of which the IETF is woven. Ad Hoc meetings that jerk the secretariat around and are disrespectful of people's biology and health are a problem. If we're going to continue this avalanche of ad hoc meetings that we call Bar BOFs, I would recommend that the Secretariat provide a web page for requesting them. The title of the web page should be Poorly Planned Meetings or something like that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [apps-discuss] Fwd: Last Call: draft-hammer-hostmeta (Web Host
Aaron Stone wrote: Additionally, the requirements to first check via HTTPS, then via HTTP, and the requirements for identical contents, are not requirements imposed by RFC 5785 -- though 5785 allows that a registration ... MAY also contain additional information, ... or protocol-specific details. A reference to that text might be useful to remind an implementer that other well-known URIs may have different protocol-specific requirements. You've found a very serious problem with this document. The assumption that when a Web-Server is accessible by HTTP on port 80 on some host, then a HTTPS-Server on port 443 will provide access to the same Web-Server by HTTPS is seriously flawed. In the survey here http://www.esecurityplanet.com/features/article.php/3890171/SSL-Certificates-In-Use-Today-Arent-All-Valid.htm a simple DNS scan for webservers found 92 million domain names (out of 119) to host a Web-Server on port 80. 34 (of the 92) millions had an HTTPS-Server running on port 443 as well. When performing an SSL-Handshakes on port 443 of these 34 millions (TLS client without server name indication (TLS Extension SNI)), only 3.17 percent of these Servers presented a server certificate matching the hostname used by the client to open the network connection. In essence this means the recommendation to first try HTTPS, then HTTP is going to result in ~99% failures to successfully access the correct Web-Server, and is therefore a _very_ impractical guidance for an RFC for the real world internet. Regards, -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
On 7/29/2010 10:00 PM, Fred Baker wrote: If we're going to continue this avalanche of ad hoc meetings that we call Bar BOFs, I would recommend that the Secretariat provide a web page for requesting them. The title of the web page should be Poorly Planned Meetings or something like that. In other words, let's make unofficial, ad hoc meetings be formal and scheduled. Fred, like you, I'm delighted to see the activity. However just because there is interest in having formal, scheduled activities that are not qualified to be BOFs, we do not need to have IETF administration support them with extra services. Let's let these self-initiated efforts remain what they are. If they can garner attendees, that's fine. If they can't, better luck next time. Even with the excellent title you suggest, the web page will move these activities down the slippery slope of formality. The way to make a more rational schedule for the week is to schedule less, not more. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
Just saying ... too late. http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 and predecessors have been out there for at least a couple of IETFs (like you guys, I'm exhausted, and in my case, too exhausted to check how many IETFs we've had such pages, but I know we had a list in Anaheim). I'm also too exhausted to think of a way to contribute to this conversation, but in a week or two, it might be helpful to resume a conversation Lars started with http://tools.ietf.org/html/draft-eggert-successful-bar-bof-00, submitted late in the week during IETF 77, and which Fred contributed helpful comments to (below). I'm sure the nice people who are bringing bar BOFs to the IETF would appreciate guidance that tells them how to best accomplish their goals ... so it is probably worth providing guidance, as best we can. The successful BOFs RFC (http://tools.ietf.org/html/rfc5434) was very helpful, and a companion document on bar BOFs would likely be helpful as well. Thanks, Spencer, who is going to bed earlier tonight than he has, since last Friday :D If we're going to continue this avalanche of ad hoc meetings that we call Bar BOFs, I would recommend that the Secretariat provide a web page for requesting them. The title of the web page should be Poorly Planned Meetings or something like that. In other words, let's make unofficial, ad hoc meetings be formal and scheduled. Fred, like you, I'm delighted to see the activity. However just because there is interest in having formal, scheduled activities that are not qualified to be BOFs, we do not need to have IETF administration support them with extra services. Let's let these self-initiated efforts remain what they are. If they can garner attendees, that's fine. If they can't, better luck next time. Even with the excellent title you suggest, the web page will move these activities down the slippery slope of formality. The way to make a more rational schedule for the week is to schedule less, not more. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
On 2010-07-30 08:47, Dave CROCKER wrote: On 7/29/2010 10:00 PM, Fred Baker wrote: If we're going to continue this avalanche of ad hoc meetings that we call Bar BOFs, I would recommend that the Secretariat provide a web page for requesting them. The title of the web page should be Poorly Planned Meetings or something like that. In other words, let's make unofficial, ad hoc meetings be formal and scheduled. Fred, like you, I'm delighted to see the activity. However just because there is interest in having formal, scheduled activities that are not qualified to be BOFs, we do not need to have IETF administration support them with extra services. Let's let these self-initiated efforts remain what they are. If they can garner attendees, that's fine. If they can't, better luck next time. Even with the excellent title you suggest, the web page will move these activities down the slippery slope of formality. The way to make a more rational schedule for the week is to schedule less, not more. I learned a lesson in, now where was it?, oh yes, Anaheim. I decided to have a Bar BOF, decided that the Hilton bar really wasn't convenient, borrowed a room from Marcia, invited a few people, was asked to advertise it on the wiki, and ended up with every seat taken in quite a big room. The discussion was good, but not overwhelmingly successful, and a lot of people just sat there quietly. (Admittedly, there was very little else to do in Anaheim for those over ten years old.) I wish it had just been six of us at the bar. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
Brian E Carpenter wrote: I wish it had just been six of us at the bar. From the BOFettes I participated in in Anaheim, I got the general impression that the intent of the get-together was to build support for turning whatever into a working group - to create yes votes (like it or not we've turned into a voting organization) and to create interest rather than sort through issues and answer questions. The most extreme example was the clouds thing, where they wanted a working group before they even had anything to work on. So I think whether six people at the bar is the right structure or a room with meeting chairs and speakers and slides is the right structure depends on whether the group is trying to solve a technical problem or a political problem. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
Fred: I had the same experience -- I guess many of us did. Last night I was at one until 9:20, when I left early to go quickly to another one where I was able to get a little food while we had a meeting. I quit at 11:45 and it was still going. Tonight I managed to get a slice of pizza before heading off to a BarBOF. But all of the BOFs that I have been at this week have been worthwhile for me. Sometimes there were conflicts and I wished I could cover more than one. Yes there were presentations but presentations are a good way to explain ideas. There is always a lot of technical discussion that can't fit into the IETF schedule. Apparently we are at a point where some of that technical discussion is appropriately done in bigger groups. I wasn't in any huge ones like you -- mine varied from 15 to 50 -- but I was glad to went to all of them. So I can't complain about the get-togethers of any sort, just that there wasn't enough time for them. I would like to encourage the use of IETF tools to announce ad hoc discussions using good teleconferencing tools, e.g. video, whiteboard, and queue management. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security) to Proposed Standa
Peter, I'm not sure if this one is already on your list or not, but I didn't see it addressed in -08: I don't think the characterization of SRV-ID as an indirect (ie. DNS resolved) identifier is correct. Whether a subject name is indirect or not, depends on the content of the identifier field and how that content was obtained, rather than on the identifier type itself. In most cases, indirect identifiers will be found in DNS-ID or CN-ID, as a result of DNS resolution of SRV, CNAME, or other records. If an application is trying to authenticate such identities, then the document needs to clearly state under what conditions it is safe to do so (DNSSEC, or a static mapping rule in the client). The document does touch on safe derivation rules later (currently in 4.2). But the direct/indirect classification of identity types needs to be corrected (or just eliminated). I said some more here: http://www.ietf.org/mail-archive/web/certid/current/msg00220.html -- Shumon Huque University of Pennsylvania. On Fri, Jul 23, 2010 at 09:25:43AM -0600, Peter Saint-Andre wrote: Sorry, I haven't yet had a chance to review the feedback that's been provided during this Last Call. I'll do that en route to Maastricht today. Next week Jeff and I will discuss in person the points that have been raised, and then we'll post further regarding our proposed changes to the spec. Peter On 7/15/10 5:08 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security ' draft-saintandre-tls-server-id-check-08.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 ietf@ietf.org mailing lists by 2010-08-12. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18634rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Shumon Huque University of Pennsylvania. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
On Jul 30, 2010, at 12:28 AM, Scott Brim wrote: So I can't complain about the get-togethers of any sort, just that there wasn't enough time for them. I would like to encourage the use of IETF tools to announce ad hoc discussions using good teleconferencing tools, e.g. video, whiteboard, and queue management. And that's the point I'm trying to get to. They have all been valuable. I do very much wish that those promoting them had done a better job of fitting them into the schedule rather than simply dropping them atop it, and in some cases remote conferencing tools will be useful choices. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 97 messages in the last 7 days. script run at: Fri Jul 30 00:53:02 EDT 2010 Messages | Bytes| Who +--++--+ 7.22% |7 | 6.08% |42865 | o...@cisco.com 6.19% |6 | 5.54% |39064 | d...@dcrocker.net 6.19% |6 | 4.99% |35160 | f...@cisco.com 3.09% |3 | 7.61% |53637 | iljit...@muada.com 4.12% |4 | 5.11% |36010 | ch...@ietf.org 4.12% |4 | 3.92% |27641 | hal...@gmail.com 2.06% |2 | 5.87% |41376 | clint.chap...@gmail.com 2.06% |2 | 5.83% |41064 | aal...@rim.com 4.12% |4 | 2.83% |19947 | jo...@iecc.com 4.12% |4 | 2.61% |18368 | t...@americafree.tv 2.06% |2 | 4.37% |30800 | rcal...@juniper.net 3.09% |3 | 2.84% |20012 | jordi.pa...@consulintel.es 3.09% |3 | 2.65% |18667 | brian.e.carpen...@gmail.com 2.06% |2 | 3.44% |24224 | iab-ch...@iab.org 3.09% |3 | 2.09% |14709 | jmamo...@gmail.com 3.09% |3 | 2.06% |14484 | a...@shinkuro.com 3.09% |3 | 1.97% |13862 | joe...@bogus.com 2.06% |2 | 1.79% |12626 | nar...@us.ibm.com 2.06% |2 | 1.64% |11566 | tglas...@earthlink.net 2.06% |2 | 1.59% |11177 | spen...@wonderhamster.org 2.06% |2 | 1.53% |10773 | scott.b...@gmail.com 2.06% |2 | 1.41% | 9965 | m...@sap.com 2.06% |2 | 1.39% | 9780 | martin.thom...@andrew.com 1.03% |1 | 1.48% |10403 | lars.egg...@nokia.com 1.03% |1 | 1.34% | 9426 | jari.ar...@piuha.net 1.03% |1 | 1.20% | 8445 | pboris...@globalenvironmentfund.com 1.03% |1 | 1.04% | 7309 | hous...@vigilsec.com 1.03% |1 | 1.02% | 7171 | adr...@olddog.co.uk 1.03% |1 | 0.98% | 6917 | j...@jlc.net 1.03% |1 | 0.94% | 6601 | amor...@amsl.com 1.03% |1 | 0.90% | 6350 | shu...@isc.upenn.edu 1.03% |1 | 0.88% | 6203 | aa...@serendipity.cx 1.03% |1 | 0.87% | 6156 | dorama...@gmail.com 1.03% |1 | 0.83% | 5882 | nicolas.willi...@oracle.com 1.03% |1 | 0.83% | 5839 | norbert.lindenb...@yahoo-inc.com 1.03% |1 | 0.81% | 5723 | dhark...@lounge.org 1.03% |1 | 0.81% | 5700 | d...@cridland.net 1.03% |1 | 0.77% | 5407 | melinda.sh...@gmail.com 1.03% |1 | 0.75% | 5267 | twa...@juniper.net 1.03% |1 | 0.73% | 5113 | stpe...@stpeter.im 1.03% |1 | 0.72% | 5109 | bob.hin...@gmail.com 1.03% |1 | 0.70% | 4946 | y...@checkpoint.com 1.03% |1 | 0.70% | 4937 | mic...@arneill-py.sacramento.ca.us 1.03% |1 | 0.68% | 4769 | hen...@levkowetz.com 1.03% |1 | 0.67% | 4715 | josh.howl...@ja.net 1.03% |1 | 0.62% | 4390 | a...@gulbrandsen.priv.no 1.03% |1 | 0.59% | 4141 | j...@nlnetlabs.nl +--++--+ 100.00% | 97 |100.00% | 704696 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'DHCPv6 options for network boot' to Proposed Standard
The IESG has approved the following document: - 'DHCPv6 options for network boot ' draft-ietf-dhc-dhcpv6-opt-netboot-10.txt as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-netboot-10.txt Technical Summary This document provides a standard mechanism for providing DHCPv6 clients with information required to bootstrap using the network. Working Group Summary This document appeared in the working group several years ago. There was substantial review and revision, which simplified the document and changed some recommendations the document made, for example replacing a recommendation to use tftp for downloads with a recommendation to use http. The review in the working group has been thorough, and there is substantial demand for this extension. Document Quality The document has undergone careful review, and the working group is satisfied with its quality. Personnel The document shepherd is Ted Lemon mel...@nominum.com. The responsible A-D is Ralph Droms rdroms.i...@gmail.com. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Mailing Lists and Internationalized Email Addresses' to Experimental RFC
The IESG has approved the following document: - 'Mailing Lists and Internationalized Email Addresses ' draft-ietf-eai-mailinglist-07.txt as an Experimental RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Alexey Melnikov and Peter Saint-Andre. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-07.txt Technical Summary This document describes considerations for mailing lists with the introduction of internationalized email addresses in RFC 5335 and makes some specific recommendations on how mailing lists should act in various situations. Working Group Summary The EAI Working Group produced this document and it is the result of solid consensus in the WG for these recommendations. Document Quality Experimental implementations of this document are currently underway, though not completed. Personnel Pete Resnick is the Document Shepherd. Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Section 1, change the 1st paragraph: OLD: This document describes considerations for mailing lists with the introduction of internationalized email addresses. NEW: This document describes considerations for mailing lists with the introduction of internationalized email addresses [RFC5335]. In Section 5, please change the 1st sentence of the 4th paragraph to read: OLD: These mailing list header fields contain URLs. NEW: Except for the List-ID header field, these mailing list header fields contain URLs [RFC3986]. In Section 5, 10th paragraph change: OLD: The List-ID header field uniquely identifies a list. NEW: The List-ID header field provides an opaque value that uniquely identifies a list. In Section 8, please replace the 1st paragraph with 2 paragraphs: OLD: Security considerations are discussed in the Framework document [EAI-Framework]. No further security considerations are raised by this document. NEW: Because use of both a UTF-8 address and an alt-address for the same entity introduces a potential ambiguity regarding the identity of list subscribers and message senders, implementers are advised to carefully handle authorization decisions regarding subscriptions, sender filters, and other common list administration features. For example, a binding between a UTF-8 address and an US-ASCII alt-address can be used by an attacker to deny another person admission to an EAI mailing list. Other relevant security considerations are discussed in the Framework document [EAI-Framework]. Please add [RFC5335] and [RFC3986] to the list of Normative References. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-tcpm-tcp-lcd-02.txt (Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD)) to Experimental RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD)' draft-ietf-tcpm-tcp-lcd-02.txt as an Experimental RFC 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 2010-08-12. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-lcd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-lcd/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
