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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.gmane.org/gmane.ietf.int/3501 <pre>All, Since the concept was well-received in Atlanta, we will be repeating the AD office hours in Orlando. We will be available on Monday from 1300 to 1500 in the yet-to-be-identified IESG breakout room. Feel free to stop by and ask questions or chat about any concerns/ideas you have about an INT WG or the area as a whole. Regards, Brian, Ralph, &amp; Ted </pre> Brian Haberman 2013-02-28T15:34:44 http://comments.gmane.org/gmane.ietf.int/3500 <pre>Thanks to many people's response and comments to draft-nachum-sarp-03. I sent an email clarifying some issues of this draft back in early Jan. Now we have updated the draft to include the clarification. In a nutshell: People are under the impression that the draft is to scale the flooding of ND messages on all links. MLD was brought up to say that ND messages are actually suppressed from flooding to links which don't have the target hosts. But that is the not the main intent of this draft. The real impact of ARP/ND in DC with massive number of hosts (or VMs) is on the L2/L3 boundary router (or Default GW). When hosts in subnet A needs to send data frames to Subnet B, the router has to 1) respond the ARP/ND requests from hosts in Subnet-A and 2) resolve target MAC for hosts in subnet-B. The second step is not only CPU intensive but also buffer intensive. There are some practices to alleviate the pain of Step 1) for IPv4, but not for IPv6 (https://datatracker.ietf.org/doc/draft-dunbar-armd-arp-nd-scaling-practices/). In order to protect routers CPU being overburdened by target resolution requests, some routers has to rate limit the Target MAC resolution requests to CPU (Glean Throttling rate in this manual). http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_ip.pdf , searching for "Glean Throttling". When the Glean Throttling rate is exceeded, the incoming data frames are dropped. In traditional Data Center, it is less of an issue because the number of hosts attached to one L2/L3 boundary router is limited by physical ports of switches/routers. When Servers are virtualized to support 30 plus VMs, the number of hosts under one router can grow 30 plus times. The solution proposed in this draft can eliminate (or reduce the likelihood of) inter-subnet data frames being dropped. In addition, the traditional DC has each subnet nicely placed in limited number of server racks, i.e. switches under router only need to deal with MAC addresses of those limited subnets. With subnets being spread across many server racks, the switches are exposed to VLAN/MAC of many subnets, greatly increasing the FDB. This draft also addresses the FDB entries explosion issue. We are looking forward to your comments and feedback to this update. Thank you very much. Linda -----Original Message----- From: internet-drafts&lt; at &gt;ietf.org [mailto:internet-drafts&lt; at &gt;ietf.org] Sent: Sunday, February 24, 2013 9:01 AM To: talmi&lt; at &gt;marvell.com Cc: Linda Dunbar; yilan&lt; at &gt;marvell.com; youval.nachum&lt; at &gt;gmail.com Subject: New Version Notification for draft-nachum-sarp-04.txt A new version of I-D, draft-nachum-sarp-04.txt has been successfully submitted by Tal Mizrahi and posted to the IETF repository. Filename: draft-nachum-sarp Revision: 04 Title: Scaling the Address Resolution Protocol for Large Data Centers (SARP) Creation date: 2013-02-24 Group: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-nachum-sarp-04.txt Status: http://datatracker.ietf.org/doc/draft-nachum-sarp Htmlized: http://tools.ietf.org/html/draft-nachum-sarp-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-nachum-sarp-04 Abstract: This document provides a recommended architecture and network operation named SARP. SARP is based on fast proxies that significantly reduce broadcast domains and ARP/ND broadcast transmissions. SARP supports smooth and fast virtual machine (VM) mobility without any modification to the VM, while keeping the connection up and running efficiently. SARP is targeted for massive scaling data centers with a significant number of VMs using ARP and ND protocols. The IETF Secretariat </pre> Linda Dunbar 2013-02-25T20:13:24 http://comments.gmane.org/gmane.ietf.int/3498 <pre> The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments' &lt;draft-ietf-intarea-nat-reveal-analysis-05.txt&gt; as Informational 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 ietf&lt; at &gt;ietf.org mailing lists by 2013-03-08. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 is 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. </pre> The IESG 2013-02-22T19:06:42 http://comments.gmane.org/gmane.ietf.int/3495 <pre>http://www.natrocheminternational.com/namzlfe/5qy5pw4nt2tlgd.8a0sx1lsyzh42qy0yzr2cu_______________________________________________ Int-area mailing list Int-area&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/int-area </pre> Derick Winkworth 2013-02-16T17:12:28 http://comments.gmane.org/gmane.ietf.int/3489 <pre>Hi all, The intarea WG will be meeting at the Orlando IETF (we have been allocated a 2 hour 20 min slot) and we are in the process of setting the agenda. Please send us your request for slots detailing * Name of the draft * Short description of why you think the item needs to be discussed in the intarea meeting * Whether the draft has already been presented or will be presented in some other wg/bof. Thanks Suresh and Julien </pre> Suresh Krishnan 2013-02-13T21:30:51 http://comments.gmane.org/gmane.ietf.int/3475 <pre>We posted this as a new WG draft a few weeks ago: https://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ All comments to date have been incorporated, so are there any further issues or suggestions? Regards Brian </pre> Brian E Carpenter 2013-02-12T11:08:40 http://comments.gmane.org/gmane.ietf.int/3471 <pre>All, I have completed my AD evaluation for the above draft and have some feedback for the group. I will focus on the substantive comments for the time being since some of them may result in re-written text in places. I will follow up with the document authors on editorial nits and such at a later time. 1. It is obvious from the way certain sections of text are written that the original intent was to make a recommendation on which of the described approaches should be used to disambiguate between multiple hosts behind a NAT/CGN. Given that the document is now simply a characterization of those mechanisms, I would suggest spending some time cleaning up the Abstract, Section 1.1, and Section 2 so that they focus on the task of describing the mechanisms, rather than mentioning abstract requirements for those mechanisms. There are concrete suggestions a little later in this note. 2. The mechanisms described in this draft fall into two broad categories, deployed and proposed. Those in the former category can be characterized based on actual usage scenarios, which would benefit the table shown in Figure 3. The latter should be described in terms of what they are proposed to do, but cannot be assessed against the same metrics as the other groups. 3. The "Requirements Language" section should be removed. As an Informational document describing mechanisms, there is no need to leverage 2119 keywords. 4. It would be useful if the third paragraph of Section 1.1 was expanded to discuss the risks in more detail. In fact, it may be clearer to understand this draft if the problem statement came before the context (Section 2). 5. Section 2 * The Observation text should provide some brief examples of how and why special treatment is needed/provided. Is it sufficient to identify the sending host? application? user? It should also note that there may be issues with the fact that some IP addresses will be shared and others may not. How does that impact the performance of these mechanisms? * I would like some text in the Objective text to explain why such sorting is needed. This relates back to the Context description in Section 1.1. * I don't think there needs to be a description of a Requirement in this document any more, so that text can be removed. 6. Section 3.1 should be removed. This is simply an analysis of the mechanisms, so there is no new work which needs requirements defined at this point. 7. In Section 4.1.2, it would be good to describe any issues that the approach has with the original use of the Identification field for fragmentation reassembly. If a middlebox changes the ID field, weird things can/will happen if those packets are fragmented somewhere. 8. I don't see a need for a forward reference in Section 4.2.2. I would suggest simply stating that the IP Option approach will support any/all transport protocols. 9. In Section 4.3.2... * I would like to see some description of what risk(s) may arise with a TCP option, even though they are apparently low probability. * Additionally, the text contains "0,103%", which I assume should be "0.103%" (i.e., 1/10th of 1%). *The third bullet mentions that having several NATs in the path may cause issues for a TCP option. Isn't this true for other approaches discussed in the document? These should be identified as well. 10. In Section 4.5.1, I would suggest adding some text that describes how to interpret Figure 2. 11. Is Section 4.6 theoretical or is there a specific reference that can be added for this technique? 12. Section 4.7.2 should clearly state that HIP is an ideal solution for this identification problem, even though the document states there is a high cost for deployment. I would also like to see some description of why HIP does not work if "the address sharing function is required to act as a UDP/TCP-HIP relay". 13. Section 4.8.2 * The text says that the ICMP approach is viable for TCP and UDP. Any reason why it may be an issue for other transport protocols (e.g., SCTP or RTP)? * I would also like to see some text describing why the approach is not compatible with cascading NATs. * The last bullet mentions FMC and Open WiFi with no context or references. These should either have references or their mention should be removed since they don't add much to the description. The same goes for their mention in Section 4.9.2 (8th bullet). 14. In Section 4.9.2 (3rd bullet), is the solution to publish this info in DNS or is that just an example approach? This should be clarified. 15. Section 5 * Shouldn't there be an additional metric that covers the impact/cost of needing client or middlebox code changes? * Where did the 100% success ratio for IP-ID come from? There have been documented cases of OSes setting the Identification field to zero. If that is true, the success ratio can't be 100% can it? * Given the goal of this document to describe these identification mechanisms, I don't see the need for the last bulleted list. Regards, Brian </pre> Brian Haberman 2013-02-11T21:11:47 http://comments.gmane.org/gmane.ietf.int/3468 <pre>Dear Internet ADs, The chairs of the intarea working group, on behalf of the working group, request that the following document be published as a Proposed Standard. Title : Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments Draft name: draft-ietf-intarea-nat-reveal-analysis-04.txt Writeup ======= (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This document does not define any protocols. It provides an analysis of multiple solutions for identifying a host when it uses an IP address that is shared among multiple subscribers behind a Carrier Grade NAT. Hence we believe that an Informational document is appropriate. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier must be unique to each host under the same shared IP address. Working Group Summary: The working group had active discussion on the draft and the current text of the draft is representative of the consensus of the working group. In particular, as a result of WG consensus, this version of the draft does not make any recommendations as to a preferred solution among those analyzed. Document Quality: The document has received adequate review. The Document Shepherd has no concerns about the depth or breadth of these reviews. This document does not define a protocol. Hence there are no implementations of this document. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Suresh Krishnan is the document shepherd. Brian Haberman is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed the draft and finds that it is ready to advance to the IESG. All issues that were raised in the working group last calls have been addressed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The document shepherd has no such concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Yes. I think the document could benefit from further review from people with Security and Privacy expertise. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There is a general concern with the document that has been raised several times over the progress of the document through the WG. Specifically, there are several people who believe that deploying IPv6 would be a much better solution that any described in this document. While that is true, the fact remains that there are existing deployments of shared IPv4 addresses that could benefit from the analysis provided in the draft. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus behind this document has been pretty stable but not very strong. In particular, the WG consensus flipped completely at one point in the process to not include a recommendation in the draft. Prior consensus was to include a recommendation. This happened between versions -02 and -03. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No errors were found on the ID nits check. There are newer versions of some of the drafts in the references. This will be updated whenever a newer version of the draft is published. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document requests no IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A Thanks Suresh </pre> Suresh Krishnan 2013-01-23T04:43:38 http://comments.gmane.org/gmane.ietf.int/3466 <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 : Using the IPv6 Flow Label for Server Load Balancing Author(s) : Brian Carpenter Sheng Jiang Willy Tarreau Filename : draft-ietf-intarea-flow-label-balancing-00.txt Pages : 13 Date : 2013-01-15 Abstract: This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-flow-label-balancing-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-01-15T15:01:23 http://comments.gmane.org/gmane.ietf.int/3465 <pre>Hi all, The adoption call on the mailing list has demonstrated consensus to adopt this draft as a wg draft. Authors, please resubmit this draft as draft-ietf-intarea-flow-label-balancing-00. Regards Suresh &amp; Julien </pre> Suresh Krishnan 2013-01-14T14:15:27 http://comments.gmane.org/gmane.ietf.int/3459 <pre>Hi all, I support to adopt this draft. It is a good use case of flow label. Best wishes Qiong _______________________________________________ Int-area mailing list Int-area&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/int-area </pre> Qiong 2013-01-04T03:08:25 http://comments.gmane.org/gmane.ietf.int/3444 <pre>Hi all, This draft has been presented at intarea face to face meetings and has received a bit of discussion. It has been difficult to gauge whether the wg is interested in this work or not. This call is being initiated to determine whether there is WG consensus towards adoption of draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-01-04. Regards Suresh &amp; Julien </pre> Suresh Krishnan 2012-12-18T12:45:47 http://comments.gmane.org/gmane.ietf.int/3440 <pre>Hi, This version has been updated following the review by Julia Renouard. Brian -------- Original Message -------- Subject: I-D Action: draft-carpenter-flow-label-balancing-02.txt Date: Wed, 05 Dec 2012 07:36:10 -0800 From: internet-drafts&lt; at &gt;ietf.org Reply-To: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the IPv6 Flow Label for Server Load Balancing Author(s) : Brian Carpenter Sheng Jiang Willy Tarreau Filename : draft-carpenter-flow-label-balancing-02.txt Pages : 13 Date : 2012-12-05 Abstract: This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-flow-label-balancing There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-flow-label-balancing-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-carpenter-flow-label-balancing-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt </pre> Brian E Carpenter 2012-12-05T15:42:39 http://comments.gmane.org/gmane.ietf.int/3437 <pre>Dear all, We submitted an updated version of this draft to list use cases which encounter the issue of host identification. The following use cases are discussed in the draft: (1) Carrier Grade NAT (CGN) (2) A+P (e.g., MAP ) (3) Application Proxies (4) Provider Wi-Fi (5) Policy and Charging Architectures (6) Cellular Networks (7) Femtocells (8) Overlay Networks (e.g., CDNs) The document does not include any solution-specific discussion. Its main goal is to identify the use cases and describe them. If you think your use case is not included in this version, please share it with us. Comments are welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces&lt; at &gt;ietf.org [mailto:i-d-announce-bounces&lt; at &gt;ietf.org] De la part de internet-drafts&lt; at &gt;ietf.org Envoyé : lundi 3 décembre 2012 08:26 À : i-d-announce&lt; at &gt;ietf.org Objet : I-D Action: draft-boucadair-intarea-host-identifier-scenarios-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Identification: Use Cases Author(s) : Mohamed Boucadair David Binet Sophie Durel Tirumaleswar Reddy Brandon Williams Filename : draft-boucadair-intarea-host-identifier-scenarios-02.txt Pages : 14 Date : 2012-12-02 Abstract: This document describes a set of scenarios in which host identification is required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-identifier-scenarios There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-boucadair-intarea-host-identifier-scenarios-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt </pre> mohamed.boucadair< at >orange.com 2012-12-03T09:07:55 http://comments.gmane.org/gmane.ietf.int/3434 <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 : Updated Specification of the IPv4 ID Field Author(s) : Joe Touch Filename : draft-ietf-intarea-ipv4-id-update-07.txt Pages : 19 Date : 2012-11-27 Abstract: The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime for all datagrams with a given source/destination/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-ipv4-id-update-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2012-11-28T00:15:02 http://comments.gmane.org/gmane.ietf.int/3432 <pre> Hello, I revised my draft-rafiee-intarea-cga-tsig incorporating your comments that I received by email. Please review my revised document. Best Regards, Hosnieh URL: http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-01.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-01 Abstract: The first step in the Transaction SIGnature (TSIG) (RFC 2845) process is the generation of a shared secret to be used between a DNS server and a host. The second step is the manual exchange of the shared secret between the DNS server and the host. This document, CGA-TSIG, proposes a possible way to automate the now manual process used for the authentication of a node with a DNS server during the DNS Update process by using the same parameters as are used in generating a secure address in IPv6 networks, i.e., Cryptographically Generated Addresses (CGA) (RFC 3972). CGA-TSIG facilitates this authentication process and reduces the time needed for DNS Updates. The current signature generation process and verification mechanism in TSIG are thus replaced with CGA. This algorithm is added, as an extension, to TSIG to eliminate the human intervention needed for generation and exchange of keys between a DNS server and a host when SEcure Neighbor Discovery (SEND) (RFC 3971) is used. </pre> Rafiee, Hosnieh 2012-11-23T09:34:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.int