http://blog.gmane.org/gmane.ietf.int hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.int/3525 <pre>Dear Joshua, Apologies for the delay to answer this message. I see your point. I will add it to the list of items to be considered for the next iteration of the document. BTW, -03 already included some of requirements which cover security aspects (see for instance REQ#1, REQ#2, REQ#3, REQ#9). Once we have a stable requirements list, we will identify the requirements which are valid for each use case: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-03#section-4.1 Cheers, Med </pre> mohamed.boucadair< at >orange.com 2013-05-07T14:50:38 http://permalink.gmane.org/gmane.ietf.int/3524 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Int-area mailing list Int-area&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/int-area </pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:50:12 http://permalink.gmane.org/gmane.ietf.int/3522 <pre>Brian, Well, partially. Since by design all packets with the same pair will always reach the same server, once you have found a victim server, you can send lots of packets to it. I agree that a DDoS from multiple sources could be a bit more difficult since the attacker would need to find the flow label for each source address to reach a given server. The block cipher algorithm that is described below uses a key. This key can be fixed by the operator. If the key is secret, then only the operator can send packets over specific parts. For attackers, the load-balancing function is similar to a non-invertible hash. This should answer some of your security concerns (at least it's not worst than hash-based load balancing) Yes and the interactions between load balancing and networking protocols is worth being discussed as well. Olivier </pre> Olivier Bonaventure 2013-04-17T17:45:10 http://permalink.gmane.org/gmane.ietf.int/3521 <pre>Hello Olivier, On 17/04/2013 12:28, Olivier Bonaventure wrote: That is an advantage from the security point of view, since it prevents an attacker from biasing the load balancing in order to focus a DOS attack on a single server. I believe that's discussed in the flow label spec. True, but there's likely to be little sympathy from the load balancer's operator, for the reason just given. We'll have a look, thanks for the reference. I believe, from the research I had to do personally when working on this draft, that there is scope for an RFC giving a general overview of load balancing. That would certainly have been a precious reference for the current draft. Regards Brian </pre> Brian E Carpenter 2013-04-17T13:43:54 http://permalink.gmane.org/gmane.ietf.int/3520 <pre>Hello, Here are some additional comments on the above draft. Section 4 suggests the utilisation of a hash to perform the load balancing based on the source-address/flow label pair. Hash functions are often used in load balancing applications. I think that it could be useful to point the advantages and the drawbacks of using hash functions for load balancing purposes. The main advantage of hash functions is that they usually exhibit the avalanche effect, i.e. a small change in the input causes a large change in the output of the function. Simulations show that this effect is important to correctly balance real traffic. However, with hash functions, this advantage comes with a drawback. It is difficult to predict the set of inputs that would provide a specific output. Being able to predict which decision will be taken by a load balancer is important for monitoring applications for example. If a network operator wants to verify the round-trip-time between two hosts when there is a load balancer in between, he/she should take into account this load balancing when defining his/her probes. A similar situation happens when a network operator wants to use traceroute to detect block holes on a load-balanced path. It should be noted that there exist functions that exhibit the avalanche effect without being one-way functions like the classical hash functions. If used in load-balancers, these functions would provide both good load balancing and predictibility which is desired for many monitoring applications. A recent paper shows how such load-balancing can be performed efficiently by using block ciphers instead of hash functions. The solution proposed in this paper could be adapted to utilise the IPv6 flow label : http://inl.info.ucl.ac.be/publications/revisiting-flow-based-load-balancing-stateless-path-selection-data-center-networks Best regards, Olivier Bonaventure </pre> Olivier Bonaventure 2013-04-17T11:28:11 http://permalink.gmane.org/gmane.ietf.int/3519 <pre>Hi Donald, Thanks for the review. A few comments below... On 17/04/2013 07:08, Donald Eastlake wrote: That is not really "on the wire" stuff though - isn't it sufficient to indicate that there are multiple methods? There doesn't seem to be a rule about that. Coincidentally, I'm in the middle of an argument about that over on apps-discuss, where we've been asked to promote some Informational documents to normative references in an Informational RFC. I think that's silly. I'd be happy to drop the distinction here. Yes, that is worth some thought. At least for flow label collisions, it's discussed in the flow label spec (hence our conversation some time ago about hash algorithms and FNV). We may be able to cover this by reference. Regards, Brian </pre> Brian E Carpenter 2013-04-17T06:37:16 http://permalink.gmane.org/gmane.ietf.int/3518 <pre>Hi, I think the draft is a good documentation of the issues and the benefits of using the IPv6 flow ID with load balancing. It would be more consistent with the completeness of the rest of the document to have a more complete list of typical load balancer server selection algorithms in the last paragraph of Section 5. There are people who believe that Informational documents can't have normative references. I am generally inclined that way myself. Various descriptions in the draft, like "statistically rare" could be made a bit more quantitative. I'm not saying a detailed numeric analysis is needed but a rough number based on reasonable simplifying assumptions might help to make things a little less fuzzy. Those are all my comments. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3&lt; at &gt;gmail.com On Tue, Apr 16, 2013 at 2:57 AM, Sheng Jiang &lt;jiangsheng&lt; at &gt;huawei.com&gt; wrote: </pre> Donald Eastlake 2013-04-17T06:08:34 http://permalink.gmane.org/gmane.ietf.int/3517 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-09.txt Pages : 23 Date : 2013-04-15 Abstract: This document is a collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-04-16T05:42:56 http://permalink.gmane.org/gmane.ietf.int/3516 <pre>Dear all, This version integrates a second set of comments received during the IESG review. The main changes are as follows: * Clarify the use of HOST_ID common to all interfaces is out of scope * Provide more explanation for the Proxy case * Record two additional limitations for the IP Option case * Add a new bullet to record the encountered issue when the tcp options space is exhausted * Rename HOST_ID to HOST_IDENT as HOST-ID is confusing for OPS (it is used to bind a license). Cheers, Med </pre> mohamed.boucadair< at >orange.com 2013-04-11T14:30:18 http://permalink.gmane.org/gmane.ietf.int/3515 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identifier (HOST_IDENT) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-08.txt Pages : 23 Date : 2013-04-11 Abstract: This document is a collection of solutions to reveal a host identifier (denoted as HOST_IDENT) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-04-11T14:11:02 http://permalink.gmane.org/gmane.ietf.int/3514 <pre>Dear all, We edited an I-D which proposes a global framework making use of the Connectivity Provisioning Profile. The document is available here: http://tools.ietf.org/html/draft-sin-sdnrg-sdn-approach-02 I'm sharing this information as it may be of interest of this working group. Comments are more than welcome on both I-Ds. Cheers, Med </pre> mohamed.boucadair< at >orange.com 2013-04-11T08:05:46 http://permalink.gmane.org/gmane.ietf.int/3513 <pre>Dear all, This version integrates the first set of comments received during the IESG review. The main changes are: * Add a sentence to clarify why no recommendation is included * Add a sentence to clarify a host can be any computer located behind a CPE or directly connected to an address-sharing function * Remove Section 1.1 and dispatch the bullets in the core text of Section 3 * Add a sentence to the privacy section to say an address-sharing function can be configured with different end-users policies * Clarify what is meant by "encrypted traffic" in Table 1 * Add a sentence to the privacy section to request specification document to check whether location information may/may not be exposed using HOST_ID solutions * Add a new items for the TCP option to mention it may interfere with the use of Fast Open extension * Add some pointers to behave documents. * Other minor edits. Cheers, Med </pre> mohamed.boucadair< at >orange.com 2013-04-10T11:20:11 http://permalink.gmane.org/gmane.ietf.int/3512 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group Working Group of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-07.txt Pages : 22 Date : 2013-04-10 Abstract: This document is a collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-04-10T08:58:06 http://permalink.gmane.org/gmane.ietf.int/3511 <pre>Sheng, Brian, el at: I reviewed draft-ietf-intarea-flow-label-balancing-00 Here are my comments: ------------------------------------- The draft is to suggest using IPv6 header's flow label field to identify different flows from IPv6 hosts. The draft tries to emphasize that the flow label can help devices along the way between Source &amp; destination to achieve better flow separation or finer tuned traffic balancing if there are multiple paths. However, the Section 3 devotes so much to various LB schemes. But many are irrelevant. There are many different types of Load Balance, the DNS based load balancing, which is often called global LB, has nothing to do with LB in front of a cluster of servers. Some description about LB in Section 3 is not quite to the point. For example, the second bullet you stated: "Another method, for HTTP servers, is to operate a layer 7 reverse proxy in front of the server farm." The LB in front of a cluster of servers is orthogonal to DNS based global LB. Your draft didn't even mention "Direct Server Return (DSR)" LB scheme which is used heavily in DC to balance load among a cluster of servers. In this scheme, all the servers in a cluster share a common IP address which is same as the LB, or use floating IP address for hosts. The figure in Page 7 is has some errors too. The DNS based Load Balancing is usually in the Access network. (I really think this figure is not necessary because it doesn't help the draft at all). The LB for Server Cluster is more likely located in a Data Center. Therefore, I suggest that you replace Section 3 with following: 3. Summary of Load Balancing Techniques: There are many different types of Load Balancing in networks. There is DNS based global LB, typically placed closer to clients, there are also LB for a cluster of servers who share same IP address as the LB, there are other LB. This draft is to describe how flow label can further optimize load balancer in front of a cluster of servers. Highlight of Load Balancing Algorithms: Typical industry standard load balancing algorithms available today include: Round Robin Least Connections Fastest Response Time Weighted Round Robin Weighted Least Connections Custom values assigned to individual servers in a pool based on SNMP or other communication mechanism 4. An improved Load Balancing Algorithms using Flow Label (you can describe how Flow Label improve the LB algorithms currently being deployed"). Linda </pre> Linda Dunbar 2013-04-05T20:53:38 http://permalink.gmane.org/gmane.ietf.int/3510 <pre>Linda, Thanks for the review. Some comments in line. I have added our co-author in cc because I'm not sure whether he's on the list. On 05/04/2013 21:53, Linda Dunbar wrote: True, but as far as I can tell this topic is quite badly known in the IETF and it's useful to give an overview for people. It can be used to select members of a single cluster, in fact I remember that technique being used in the very early days of cluster computing. I agree that today it's normally used for wide area LB, so we can clarify that in the text. Yes, maybe the text needs to be broken up into separate paragraphs. We didn't think this was relevant because it is part of the magic *behind* the load balancing point (i.e. the flow label has already been analysed before sending the packet on to the individual server). We can certainly explain that point. Similarly we didn't think that the actual LB algorithm (round robin etc.) was relevant. See above - we are not talking about DNS for wide-area LB, but for flipping the address within one site. See above - we think it helps people who are new to the topic. More likely than what? We don't say anything about where the server cluster lives. Regards Brian </pre> Brian E Carpenter 2013-04-06T07:13:47 http://permalink.gmane.org/gmane.ietf.int/3509 <pre>Some time back, Ron Bonica asked for a document describing policies for when and when not to add new message types to ICMP. At this point we've gotten feedback from participants in the OPS area and from specialists outside the IETF, and would like to invite broader review before moving it towards publication. Thanks, Melinda and Carlos -------- Original Message -------- Subject: New Version Notification for draft-shore-icmp-aup-03.txt Date: Tue, 26 Mar 2013 11:54:43 -0700 From: internet-drafts&lt; at &gt;ietf.org To: melinda.shore&lt; at &gt;nomountain.net CC: cpignata&lt; at &gt;cisco.com A new version of I-D, draft-shore-icmp-aup-03.txt has been successfully submitted by Melinda Shore and posted to the IETF repository. Filename: draft-shore-icmp-aup Revision: 03 Title: An Acceptable Use Policy for New ICMP Types and Codes Creation date: 2013-03-25 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-shore-icmp-aup-03.txt Status: http://datatracker.ietf.org/doc/draft-shore-icmp-aup Htmlized: http://tools.ietf.org/html/draft-shore-icmp-aup-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-shore-icmp-aup-03 Abstract: Concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not. In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for the future. The IETF Secretariat </pre> Melinda Shore 2013-03-26T19:02:16 http://permalink.gmane.org/gmane.ietf.int/3508 <pre>Hi all, The draft minutes from the Orlando intarea meeting are now available at http://www.ietf.org/proceedings/86/minutes/minutes-86-intarea Please review these minutes and send us changes/additions by April 27, 2013. We would like to thank Stuart Cheshire for taking the minutes. Regards Suresh &amp; Julien </pre> Suresh Krishnan 2013-03-26T04:39:28 http://permalink.gmane.org/gmane.ietf.int/3507 <pre>Suresh, RFC 4389 is about proxying between multiple interfaces when classic bridging is not possible, while as the proxy described in SARP is about classic bridged network spanning many locations (server racks). RFC4389 specifically stated that it is not applicable to classic bridging. Even though RFC 4389 describes how a "Proxy" interface caches the neighbor entries, it states in Section 4.1.3.1 that "no NA is generated". The Section 1.2 of the "draft-nachum-sarp-4" has stated: "Note: The Guidelines to proxy developers [RFC4389] have been carefully considered for the SARP protocols. The section 3.3 has demonstrated how SARP works when VMs are moved from one segment to another." Linda </pre> Linda Dunbar 2013-03-14T15:18:28 http://permalink.gmane.org/gmane.ietf.int/3506 <pre>Hi Suresh, all, A new version incorporating the requested changes is online: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-06 Please see inline. Cheers, Med Med: As HOST_ID is introduced in Section 2, the new text is now: Section 3 discusses privacy issues common to all candidate solutions. It is out of scope of this document to elaborate on privacy issues specific to each solution. Med: The new text is: HOST_ID is not designed to reveal the identity of a user, a subscriber, or an application. HOST_ID is designed to identify a host under a shared IP address. Med: The document does not say an http proxy is an address sharing device. Section 4 analyzes the scenario where the address sharing function is able to inject such header. Section 2 says: Within this document, we assume the address-sharing function injects the HOST_ID. Med: Changed to HTTP message. </pre> mohamed.boucadair< at >orange.com 2013-03-11T10:33:39 http://permalink.gmane.org/gmane.ietf.int/3504 <pre>Given the wide-spread view that hop-by-hop-options aren't really usable over the general internet, I have generated a version of ALFI that contains an alternative that doesn't need hop-by-hop options. Thanks to Toerless Eckert for pointing out that routers nowadays have what's needed to make this approach more usable. It is also easier to implement on a general-purpose correspondent node. I'd like to hear some opinions, on this list and/or in the hallways. (I won't be able to make the INTAREA meeting itself as it is on top of ROLL.) Htmlized: http://tools.ietf.org/html/draft-bormann-intarea-alfi-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-bormann-intarea-alfi-03 Grüße, Carsten </pre> Carsten Bormann 2013-03-11T01:35:23 http://permalink.gmane.org/gmane.ietf.int/3503 <pre>Hi all, These comments were received on the IETF discussion list during the IETF last call. http://www.ietf.org/mail-archive/web/ietf/current/msg77707.html http://www.ietf.org/mail-archive/web/ietf/current/msg77273.html Thanks Suresh -------- Original Message -------- Subject: Re: Last Call: &lt;draft-ietf-intarea-nat-reveal-analysis-05.txt&gt; (Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments) to Informational RFC Date: Mon, 25 Feb 2013 11:33:07 -0800 From: SM &lt;sm&lt; at &gt;resistor.net&gt; To: &lt;ietf&lt; at &gt;ietf.org&gt; At 11:06 22-02-2013, The IESG wrote: My comments should not be read as a statement of support. :-) In Section 1: "Section 3 discusses privacy issues common to all HOST_ID solutions. It is out of scope of this document to elaborate on privacy issues specific to each solution." I suggest explaining what "HOST_ID" is. In Section 2: "HOST_ID does not reveal the identity of a user, a subscriber or an application." I suggest adding an explanation for that statement. In Section 4.4.1: "For HTTP, Forwarded header ([I-D.ietf-appsawg-http-forwarded]) can be used to display the original IP address when an address sharing device is involved." A HTTP proxy is not an address sharing device in my opinion. "The address sharing device has to strip all included Forwarded headers before injecting their own." In Section 4.4.2: "Injecting Forwarded header also introduces some implementation complexity if the HTTP packet is at or close to the MTU size." What is a HTTP packet? Regards, -sm </pre> Suresh Krishnan 2013-03-10T17:55:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.int