http://blog.gmane.org/gmane.ietf.pce hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.pce/2941 <pre>Dear WG, Following the discussion about the future of the aforementioned document and the feedback sent to the list, this message starts a poll for the adoption of draft-farrkingel-pce-questions-03 by the PCE WG. Pay attention to the document scope: the goal is _not_ to leave the I-D open to gather all questions about PCE, but to store some useful text associated to PCE by moving forward as an informational document. Please send your support/opposition to the PCE mailing list (the latter typically requiring some explanation). Detailed comments on the I-D are also welcome. Thanks, JP &amp; Julien </pre> Julien Meuric 2013-06-19T13:38:06 http://comments.gmane.org/gmane.ietf.pce/2939 <pre>Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04, Please find bellow some comments regarding the PCEP P2MP Procedures draft (sorry for sending them after the 2 weeks deadline for the LC comments): - There is a strange page jump in the Terminology section. After "RFC5862]" and "ABR: " there is whole blank page… - Terminology section: Blank line missing between Transit/branch domain and VSPT - During the document there are 3 different acronyms "P2MP LSP" (section 3 ) "P2MP TE-LSP" (this one only in section 6) and "P2MP TE LSP" (the most common in the document). I suggest aligning the terminology and always use the same term to avoid confusion. . For "historical" reasons, "P2MP TE LSP", used in RFC 4461 seems appropriate. The definition of P2M2 TE LSP used in RFC 4661 may be cited too in the terminology section for completeness. - In the terminology section the term "Boundary node (BN) is defined. However, later on, the term "border node" is also used, presumably as an synonym. I suggest either choose one term for the whole document or include the term border node too in the terminology. - Section 3. The sentence "A sub-tree is a part of the P2MP tree describing how the root or an intermediate P2MP LSPs minimizes packet duplication when P2P TE sub-LSPs traverse common links" is hard to understand (maybe there is a typo and it should say "the root of an intermediate P2P LSP"). - The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined in RFC 4661. Maybe it should be worth adding the sub-LSP terms it to the terminology section. - In section 4 the term "sequence of domains" is also used to refer to the path domain tree. This introduces confusion, as there is also a "domain sequence" term which applies only to P2P. Please use always "path domain tree" -Section 4, 2nd paragraph, "domain path tree", use the term "path domain tree" defined in the terminology section. - Section 4, figure 1 legend is "Domain sequence tree". This term is not defined in the terminology. I would prefer to stick to the term "Path Domain tree". Sorry to be picky about the terminology, but reading the document is hard when the terms are mixed as they are very alike…. - Section 4, assumptions, first bullet. Where it says " each of the P2MP destination" it should day "each of the P2MP destinations". Section 4, assumption 1, "or PCE sequence (i.e. PCE that serves each domain in the path domain tree)". I don't get this point…. Initially it was stated that the path domain tree is known. In this point, is it suggested an alternative to knowing the path domain tree? That is, instead of assuming that the path domain tree is known, what is known is a set of PCEs? Please clarify Section 4, assumption 1, How is the set of PCEs and their relationships exchanged? What are the relationships that need to be exchanged? Section 4, assumptions, I guess, there is an (maybe obvious) assumptions that the association domain - PCE is known in advance. Sesction 4, assumption 4. "The boundary nodes to use on the LSP are pre-determined". Does this mean then that both the path domain tree AND the boundary nodes are known in advance for each possible P2MP combination? At this point there is something I miss… Later, in section 7, it is mentioned that a core tree is computed. However, it seems from the assumptions that the core tree is fixed in advance… Maybe I am mis-interpreting the assumptions… Please clarify the assumptions of what is really pre-determined and what is computed. Section 5. requirement 4. I suggest using better "PCReq and PCEReq messages" using the terminology of RFC 5440. Section 5. The requirements from 5 to 8 are not written like requirements. I suggest re-writing them with requirements language. Section 6. Objective function 3. The definition of the core tree in the terminology section considers ONLY entry boundary nodes as leaves. However, it seems here both entry and exit BNs are considered. Please clarify… (maybe it should be mentioned only BNs without distinction among entry or exit). Section 6. Objective function 3 is about limiting the number of entry points to a domain. Why would there be more that one entry point to a domain? I would expect multiple exit points (that is, several boundary nodes to exit to other domains in the tree). Also, given that, by the assumptions in section 4, the path domain tree AND the boundary nodes are flxed, I do not know if this objective function has any impact at all…. In any case, limiting the number of entry points may an additional constraint to the previous objective functions… It seems more a metric constraint rather than an objective function.. Also, is it considered that several of this objective functions can be applied or combined? Section 6, objective function 4… I don't get that one… could you clarify it? Section 7.1 The sentence "An optimal core-tree [based on the OF] will be computed with analyzing the nodes and links within the domains" sounds a bit strange… maybe the "with" is not needed in the sentence? Also.. Previously it was mentioned that the core-tree was formed only considering entry and exit nodes, but now, it seems that the core-tree is obtained taking into account the whole set of nodes and links… Please clarify here (or clarify objective function 2 where it says "formed by considering only the entry and exit nodes"…) - Section 7.3 When mentioning the request with the C bit set I suggest adding "(defined later in section 7.4.1 of this document)", as it is a new flag… - Section 7.4.2. I guess "domain-sequence" is really the domain tree… One question… the PCE sequence… is a PCE tree? And that's all :-) I hope the comments can be useful to improve the readability of the draft. Best Regards, Oscar ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx </pre> Oscar González de Dios 2013-06-17T16:09:05 http://comments.gmane.org/gmane.ietf.pce/2931 <pre>Hi chairs and working group, Dan and I are wondering what to do with this draft. It seems that a number of people have been reading it and have found it useful or at least stimulating. At the moment, it represents just the rambling thoughts of two individuals, so my question is really whether the WG thinks this would be something that could be usefully published as an RFC or should be judged to have served its purpose now and allowed to die. If published as an RFC there would be a number of ways to go forward: adoption by the WG and subsequent edits; publication of the individual I-D under the care of the WG (still review and edit, but faster); publication as an individual I-D (under the care of an AD with review by the PCE working group). We'd be interested to know what you think before we decide what action to request for the document. And, of course, any issues or thoughts on the document would be very welcome. Thanks, Adrian </pre> Adrian Farrel 2013-06-12T14:27:04 http://comments.gmane.org/gmane.ietf.pce/2930 <pre>Hi PCE'rs. This message ignites a 2-week-long WG last call for draft-ietf-pce-vendor-constraints-10. Please send your comments on the I-D to the PCE mailing list by Wednesday June 26. Best regards, JP &amp; Julien </pre> Julien Meuric 2013-06-12T08:08:49 http://comments.gmane.org/gmane.ietf.pce/2927 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Requirements for GMPLS applications of PCE Author(s) : Tomohiro Otani Kenichi Ogaki Diego Caviglia Fatai Zhang Cyril Margaria Filename : draft-ietf-pce-gmpls-aps-req-08.txt Pages : 12 Date : 2013-06-10 Abstract: The initial effort of the PCE (Path computation element) WG is specifically focused on MPLS. As a next step, this draft describes functional requirements for GMPLS application of PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-gmpls-aps-req-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-aps-req-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-06-10T17:00:05 http://comments.gmane.org/gmane.ietf.pce/2924 <pre>Strangely I sent this email to CCAMP not PCE. Here is the thread for your information. Adrian </pre> Adrian Farrel 2013-06-07T12:34:31 http://comments.gmane.org/gmane.ietf.pce/2919 <pre>A new version of the stateful pce applicability draft was posted yesterday. In the interest of making progress on this document, the authors would like to solicit review, comments and discussion from the working group, before the next IETF meeting. URL: http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04.txt Status: http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app Htmlized: http://tools.ietf.org/html/draft-zhang-pce-stateful-pce-app-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-zhang-pce-stateful-pce-app-04 Ina and Xian on behalf of all the authors </pre> Ina Minei 2013-05-26T21:51:55 http://comments.gmane.org/gmane.ietf.pce/2918 <pre> The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Requirements for GMPLS applications of PCE' &lt;draft-ietf-pce-gmpls-aps-req-07.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-06-07. 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 The initial effort of the PCE WG is specifically focused on MPLS (Multi-protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1869/ </pre> The IESG 2013-05-25T01:26:29 http://comments.gmane.org/gmane.ietf.pce/2917 <pre>Hi, I have conducted my usual AD review intended to catch any issues before IETF last call and IESG evaluation. With this document my comments are relatively minor and so I would like you to consider them as part of the IETF last call which I will start shortly. Thanks for the work. Adrian --- idnits shows a couple of issues with your references == Unused Reference: 'RFC3945' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC4927' is defined on line 402, but no explicit reference was found in the text These both seem like relevant references and I suggest that you find a place in the text to point to them. --- Some work on acronyms, please. PCE needs to be expanded on first use in the Abstract and the main text (not on the second use :-) OTOH, MPLS and GMPLS do not need to be expanded. PCC shows up in section 2.1 PCReq and PCRep are in 2.1 (but expanded a little later) P2MP is in section 2.2 ERO and XRO show in section 3.1 PCEP shows in section 3.2 --- Section 1 para 4 seems to say that SRLG is covered in RFC 3473. Are you sure? Or do you need a different reference? --- In Section 3.1 reqs (1), (2) and (3) you appear to be limiting the supported values to only those listed or those in the referenced RFCs. You may do better to say less. Just point at the base definition of the signaling fields (in RFC 3473?) and then say "all current and future values". --- Section 6 Julien Meuric not Meulic </pre> Adrian Farrel 2013-05-24T21:50:10 http://comments.gmane.org/gmane.ietf.pce/2916 <pre> -----Original Message----- From: Quintin Zhao [mailto:quintin.zhao&lt; at &gt;huawei.com] Sent: 2013年5月21日 11:59 To: 'Julien Meuric'; 'draft-ietf-pce-pcep-inter-domain-p2mp-procedures&lt; at &gt;tools.ietf.org' Subject: RE: Last IPR Check on draft-ietf-pce-pcep-inter-domain-p2mp-procedures Dear Julien, I am not aware any other IPR other than the IPR disclosed already. Thanks, Quintin -----Original Message----- From: Julien Meuric [mailto:julien.meuric&lt; at &gt;orange.com] Sent: 2013年5月21日 4:54 To: draft-ietf-pce-pcep-inter-domain-p2mp-procedures&lt; at &gt;tools.ietf.org Cc: pce&lt; at &gt;ietf.org Subject: Last IPR Check on draft-ietf-pce-pcep-inter-domain-p2mp-procedures Dear authors of the aforementioned document, Has all IPR that applies to draft-ietf-pce-pcep-inter-domain-p2mp-procedures been disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more details) Note that an associated IPR was disclosed in last February. A response from each of you is expected. Regards, JP &amp; Julien _______________________________________________ Pce mailing list Pce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pce </pre> Quintin Zhao 2013-05-21T20:28:53 http://comments.gmane.org/gmane.ietf.pce/2911 <pre>Changed milestone "Submit the stateful PCE document(s) to the IESG", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/pce/charter/ </pre> IETF Secretariat 2013-05-21T11:01:55 http://comments.gmane.org/gmane.ietf.pce/2909 <pre>Dear authors of the aforementioned document, Has all IPR that applies to draft-ietf-pce-pcep-inter-domain-p2mp-procedures been disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more details) Note that an associated IPR was disclosed in last February. A response from each of you is expected. Regards, JP &amp; Julien </pre> Julien Meuric 2013-05-21T08:53:33 http://comments.gmane.org/gmane.ietf.pce/2908 <pre>Hi all. This message ignites a two-week period to collect feedback on draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04. Please send your comments on the document to the PCE mailing list by Tuesday June 4, noon UTC. Regards, JP &amp; Julien </pre> Julien Meuric 2013-05-21T08:42:43 http://comments.gmane.org/gmane.ietf.pce/2906 <pre>The Path Computation Element (pce) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ------------------------------------------------ Current Status: Active Working Group Chairs: JP Vasseur &lt;jpv&lt; at &gt;cisco.com&gt; Julien Meuric &lt;julien.meuric&lt; at &gt;orange.com&gt; Secretaries: Daniel King &lt;daniel&lt; at &gt;olddog.co.uk&gt; Assigned Area Director: Adrian Farrel &lt;adrian&lt; at &gt;olddog.co.uk&gt; Mailing list Address: pce&lt; at &gt;ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/pce Archive: http://www.ietf.org/mail-archive/web/pce/ Charter of Working Group: The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on each head-end LSR. The PCE WG works on application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG determines requirements for extensions to existing routing and signaling protocols in support of the PCE architecture and the signaling of inter-domain paths (e.g. RSVP-TE and its GMPLS variations). Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The WG also works on the mechanisms to for multi-layer path computation and PCEP extensions for communication between several network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) while keeping consistency with the GMPLS architecture specified in the CCAMP WG. Work Items: - PCEP extensions for MPLS and GMPLS Traffic Engineered LSP path computation models involving PCE(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with protocol specific Working Group (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for communication in the various GMPLS-controlled networks, including WSON. - Definition of PCEP extensions for path computation in multi-layer networks. - Definition of the PCEP extensions used by a stateful PCE for recommending a new path for an existing or new LSP to the PCC/PCE. Further protocol extensions must cover the case where the recommendation is not followed by the PCC/PCE. Milestones: Done - Submit first draft of PCE architecture document Done - Submit first draft of PCE discovery requirements and protocol extensions documents Done - Submit first draft of the PCE communication protocol requirements Done - Submit first draft of the definition of objective metrics Done - Submit first draft of the PCE communication protocol specification Done - Submit PCE architecture specification to the IESG to be considered as Informational RFC Done - Submit first draft of the MIB module for the PCE protocol Done - Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Done - Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Done - Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Done - Submit first draft of the PCE P2MP communication requirements Done - Submit first draft of the PCE P2MP PCEP protocol extensions Done - Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC Done - Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC Done - Submit applicability and metrics documents to the IESG Oct 2011 - Submit WSON requirements to the IESG to be considered as an Informational RFC Dec 2011 - Submit extensions for hierarchical PCE path computation model as WG document Jan 2012 - Submit the PCEP MIB to the IESG to be considered as a Proposed Standard Jan 2012 - Submit P2MP MIB as a WG document Feb 2012 - Submit the discovery MIB to the IESG to be considered as a Proposed Standard Feb 2012 - Submit inter-layer extensions to the IESG to be considered as a Proposed Standard Mar 2012 - Submit inter-area/AS applicability statement to the IESG as an informational RFC Mar 2012 - Submit PCEP extensions for WSON as a WG document Apr 2012 - Submit the GMPLS requirements to the IESG to be considered as an Informational RFC Jun 2012 - Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard Aug 2012 - Submit PCEP extensions for WSON to the IESG to be considered as a Proposed Standard Oct 2012 - Submit P2MP MIB to the IESG to be considered as a Proposed Standard Feb 2013 - Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard Mar 2013 - Evaluate WG progress, recharter or close </pre> The IESG 2013-05-17T16:01:07 http://comments.gmane.org/gmane.ietf.pce/2903 <pre>Hi, The IESG has just approved your recharter without sending it for external review. The charter page will be updated in due course. Thanks, Adrian </pre> Adrian Farrel 2013-05-16T17:07:41 http://comments.gmane.org/gmane.ietf.pce/2901 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths Author(s) : Quintin Zhao Dhruv Dhody Zafar Ali Daniel King Ramon Casellas Filename : draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04.txt Pages : 21 Date : 2013-05-15 Abstract: The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes an experiment to provide procedures and extensions to the PCE communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-inter-domain-p2mp-procedures There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-05-15T07:16:49 http://comments.gmane.org/gmane.ietf.pce/2897 <pre>Hi, No-one came back to me on the list or in private in the last (almost) three weeks with any comments. Maybe everyone is happy/shy/vacationing. Anyway, the authors have no more work in the queue for this I-D and believe it is cooked. Chairs, over to you. Thanks, Adrian TLV the </pre> Adrian Farrel 2013-05-12T19:23:36 http://comments.gmane.org/gmane.ietf.pce/2894 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Extensions for Stateful PCE Author(s) : Edward Crabbe Jan Medved Ina Minei Robert Varga Filename : draft-ietf-pce-stateful-pce-04.txt Pages : 54 Date : 2013-05-10 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-05-10T16:58:02 http://comments.gmane.org/gmane.ietf.pce/2881 <pre>Dear authors of the aforementioned I-D, Are you aware of any other IPR that applies to draft-ietf-pce-gmpls-aps-req? If so, has all this IPR been disclosed in compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more details) Note that an IPR was disclosed on this I-D last summer. A response from each of you is expected. Regards, JP &amp; Julien </pre> Julien Meuric 2013-04-30T09:12:57 http://comments.gmane.org/gmane.ietf.pce/2880 <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. _______________________________________________ Pce mailing list Pce&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pce </pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:30:14 http://comments.gmane.org/gmane.ietf.pce/2879 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Conveying Vendor-Specific Constraints in the Path Computation Element Protocol Author(s) : Fatai Zhang Adrian Farrel Filename : draft-ietf-pce-vendor-constraints-10.txt Pages : 11 Date : 2013-04-22 Abstract: The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-vendor-constraints There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-vendor-constraints-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-vendor-constraints-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-04-23T05:05:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.pce