http://permalink.gmane.org/gmane.ietf.p2psip hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.p2psip/2784 <pre>Hi, Hereby we are issuing a WGLC for draft-ietf-p2psip-sip-09. The WGLC will be open till the 20th of May. We kindly ask the WG to review the document and provide comments. If you have no comments and think the document is ready to be submitted to IESG, please do send a note stating that to the WG ML. Additional information about the document is below: Title : A SIP Usage for RELOAD Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-09.txt Pages : 19 Date : 2013-02-25 Abstract: This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system and includes a lookup service </pre> Carlos Jesús Bernardos Cano 2013-05-04T17:33:18 http://permalink.gmane.org/gmane.ietf.p2psip/2783 <pre>Hi, I've just gone through the revised documents authors provided after my first round of comments. I'm happy to see that most of the comments have been now introduced. I have now only a few minor editorial ones, that can be dealt with in parallel with the next steps. My reviews are attached to this e-mail (I added comments to the PDF version of each draft). Authors, please check the attachments!! :D Thanks for the nice job. Thanks, Carlos _______________________________________________ P2PSIP mailing list P2PSIP-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/p2psip </pre> Carlos Jesús Bernardos Cano 2013-05-04T17:23:34 http://permalink.gmane.org/gmane.ietf.p2psip/2782 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This is the last call for participation for a RELOAD Interoperability Testing event in Berlin, Germany on July 27 and 28. On the Saturday, the event will be held at the Freie Universitaet Berlin. On the Sunday the event will be held at the venue of IETF 87. Many thanks to the Freie Universitaet Berlin and the IETF for providing the resources for this. If you have a RELOAD implementation, complete or partial, and want to participate, please send an email to reloadit-registration-V0vwV6LTwHHhIp2ksRZFZA&lt; at &gt;public.gmane.org, with the following information: - - Implementation name - - Contact email - - Number of persons attending. Note that the event will be canceled if there is not at least 4 different implementations registered by end of May, so please register as soon as possible. You do not need a complete implementation to participate and be assured that the name of the participants will be kept confidential. Remember that all participants can have one or</pre> Marc Petit-Huguenin 2013-05-02T14:40:12 http://permalink.gmane.org/gmane.ietf.p2psip/2781 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I just release a new version of this draft that was presented in Atlanta. The draft contains a new Implementation Status section, following the advices of draft-sheffer-running-code. Comments, questions and suggestions are welcome. Thanks. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-p2psip-reload-eku-01.txt Date: Mon, 29 Apr 2013 20:31:07 -0700 From: internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org Reply-To: internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org To: i-d-announce-EgrivxUAwEY&lt; at &gt;public.gmane.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using Extended Key Usage (EKU) for REsource LOcation And Discovery (RELOAD) X.509 Certificates Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-p2psip-reload-eku-01.txt Pages : 5 Date : 2013-04-29 Abstract: This document describes an Extended Key Usage (EKU) X.509 certificate </pre> Marc Petit-Huguenin 2013-04-30T15:41:17 http://permalink.gmane.org/gmane.ietf.p2psip/2780 <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</pre> johnsonhammond1-revL73yDgGBWk0Htik3J/w< at >public.gmane.org 2013-04-27T17:31:20 http://permalink.gmane.org/gmane.ietf.p2psip/2779 <pre>Hi, I have several questions regarding certificates with multiple NodeIDs. It seems that different parts in the draft contradict each other. First, section 6.6.1 defines requirements for future overlay link protocols. I suppose, that current overlay link protocol must meet these requirements. Certificates with multiple NodeIDs sometimes violate this requirement. Unless a connection was formed as a result of exchanging Attach messages, it is impossible to associate an endpoint and its NodeID, which is the case when new node connects to BootstrapPeer. As a consequence several reload requirements are hard or even impossible to implement IMHO. The first requirement is that ConnectionTable SHOULD use some indexes instead of mapping NodeIds to (D)TLS Connections. The second requirement is in section 6.1.2 The routing decisions must be made based on ForwardingHeader alone, and a ForwardingHeader does not contain information about type of the message, being sent. So this is practically NOT implementable. Sec</pre> Polina Goltsman 2013-04-22T18:30:39 http://permalink.gmane.org/gmane.ietf.p2psip/2778 <pre>A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : An extension to RELOAD to support Relay Peer Routing Author(s) : N. Zong, et al Filename : draft-ietf-p2psip-rpr Pages : 15 Date : April 16, 2013 This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential use cases where this extension can be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader imple</pre> Internet-Drafts-EgrivxUAwEY< at >public.gmane.org 2013-04-16T16:11:38 http://permalink.gmane.org/gmane.ietf.p2psip/2777 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This is a call for participation for a RELOAD Interoperability Testing event in Berlin, Germany on July 27 and 28. On the Saturday, the event will be held at the Freie Universitaet Berlin. On the Sunday the event will be held at the venue of IETF 87. Many thanks to the Freie Universitaet Berlin and the IETF for providing the resources for this. If you have a RELOAD implementation, complete or partial, and want to participate, please send an email to reloadit-registration-V0vwV6LTwHHhIp2ksRZFZA&lt; at &gt;public.gmane.org, with the following information: - - Implementation name - - Contact email - - Number of persons attending. Note that the event will be canceled if there is not at least 4 different implementations registered by end of May, so please register as soon as possible. You do not need a complete implementation to participate and be assured that the name of the participants will be kept confidential. Remember that all participants can have one or more R</pre> Marc Petit-Huguenin 2013-04-11T15:22:49 http://permalink.gmane.org/gmane.ietf.p2psip/2776 <pre>OK, thanks. Carlos On Wed, 2013-04-10 at 01:07 +0000, Zongning wrote: _______________________________________________ P2PSIP mailing list P2PSIP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/p2psip </pre> Carlos Jesús Bernardos Cano 2013-04-10T01:15:02 http://permalink.gmane.org/gmane.ietf.p2psip/2775 <pre>Hi, Carlos, I made mistake (using wrong file) when I tried to submit RPR draft, so that I could not do automatic post via IETF portal. I have asked 'internet-drafts&lt; at &gt;ietf.org' to do manual post and hope to see RPR draft in IETF repository soon. Sorry about that. -Ning _______________________________________________ P2PSIP mailing list P2PSIP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/p2psip </pre> Zongning 2013-04-10T01:07:42 http://permalink.gmane.org/gmane.ietf.p2psip/2774 <pre>Hi Roni, Sorry for my late reply. I think I'm fine with your proposed text. I've seen that you have updated DRR. Nnce you update RPR draft, I'll review both documents again and post any further comments that I have (if any), as part of my shepherd review. Thanks, Carlos On Sat, 2013-03-30 at 10:46 +0300, Roni Even wrote: </pre> Carlos Jesús Bernardos Cano 2013-04-10T01:00:40 http://permalink.gmane.org/gmane.ietf.p2psip/2773 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : An extension to RELOAD to support Direct Response Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-drr-05.txt Pages : 17 Date : 2013-04-08 Abstract: This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential cases where this extension can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-drr There's also a htmlized version av</pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2013-04-08T11:23:21 http://permalink.gmane.org/gmane.ietf.p2psip/2772 <pre> If you are interested in this type of thing, I highly recommend reading "A Model to Quantify the Success of a Sybil Attack Targeting RELOAD/Chord Resources", by Uruena, M. ; Cuevas, R. ; Cuevas, A. ; Banchs, A. in Communications Letters, IEEE Volume: 17, Issue: 2 http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6412682&amp;tag=1 </pre> Cullen Jennings (fluffy 2013-04-04T18:12:10 http://permalink.gmane.org/gmane.ietf.p2psip/2771 <pre>Hi Carlos, The current text in the security section of both drafts is "As a routing alternative, the security part of RPR conforms to section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security." I saw you comment "I think this sections has to be extended. It is not clear to me how the proposed approach conforms to -base security without providing more details. How DoS attachs would be avoided for example, by trying to forge the destination address". I am not sure what we can add here. The security section of the base draft starts with an overview that references RFC5765. DRR and RPR are only adding routing options. DRR provides a direct path back to the source and as such reduce the problem on malicious nodes on the route to affect the route back. The digital signatures defined in the based draft protects against changes of the forwarding header. RPR as specified in the draft (section3.2) is using a trusted node close to the initiating node, using a trusted nodes is recommend</pre> Roni Even 2013-03-30T07:46:06 http://permalink.gmane.org/gmane.ietf.p2psip/2770 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : P2P Overlay Diagnostics Author(s) : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Filename : draft-ietf-p2psip-diagnostics-11.txt Pages : 30 Date : 2013-03-24 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks. The IETF </pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2013-03-25T06:04:34 http://permalink.gmane.org/gmane.ietf.p2psip/2769 <pre>Hi, A draft of the minutes is available: http://www.ietf.org/proceedings/86/minutes/minutes-86-p2psip Many thanks Dean for providing the minutes. Please provide your feedback by the end of next week. Thanks, Brian &amp; Carlos </pre> Carlos Jesús Bernardos Cano 2013-03-14T22:25:37 http://permalink.gmane.org/gmane.ietf.p2psip/2768 <pre>Hi Carlos, You made a comment about registering the forward option flag and forward option type with IANA. These parameters are defined in the p2psip base draft and flags values are assigned over there. So if there is a need for IANA registry this should be specified in the base draft which is the main document Roni -----Original Message----- From: p2psip-bounces-EgrivxUAwEY&lt; at &gt;public.gmane.org [mailto:p2psip-bounces-EgrivxUAwEY&lt; at &gt;public.gmane.org] On Behalf Of Carlos Jes?s Bernardos Cano Sent: 22 January, 2013 1:51 PM To: p2psip-EgrivxUAwEY&lt; at &gt;public.gmane.org Cc: draft-ietf-p2psip-drr-nZLwadvX8BDR74oF6e/6QQ&lt; at &gt;public.gmane.org; draft-ietf-p2psip-rpr-nZLwadvX8BDR74oF6e/6QQ&lt; at &gt;public.gmane.org Subject: [P2PSIP] Review of DRR and RPR documents Hi, As agreed during the last meeting, I've performed a review of draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to shipping them to the IESG for publication. My reviews are attached to this e-mail (I added comments to the PDF version of each draft, hope this is </pre> Roni Even 2013-03-13T12:45:42 http://permalink.gmane.org/gmane.ietf.p2psip/2767 <pre>Hi folks, The materials are now available on the meetings material site. Thanks to all presenters for providing the slides timely in advance: https://datatracker.ietf.org/meeting/86/materials.html For those here in Orlando, we would need a couple of minute takers and a jabber scribe. If you can kindly volunteer in advance, that would be highly appreciated. Thanks! </pre> Carlos Jesús Bernardos Cano 2013-03-11T14:06:59 http://permalink.gmane.org/gmane.ietf.p2psip/2766 <pre>Hi all, The final agenda (we just did a minor update) is posted on the IETF datatracker site. Presenters: (if you have not done it already) please send your slides to the chairs Sunday afternoon the latest. Thanks! Brian and Carlos On Wed, 2013-02-27 at 19:45 +0100, Carlos Jesús Bernardos Cano wrote: _______________________________________________ P2PSIP mailing list P2PSIP&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/p2psip </pre> Carlos Jesús Bernardos Cano 2013-03-06T09:34:59 http://permalink.gmane.org/gmane.ietf.p2psip/2765 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/26/2013 09:50 AM, Marc Petit-Huguenin wrote: Reading the notes I took when trying to implement this, there is another issue which is that DTLS was never defined as transport for STUN (or TURN). So that would require an additional draft. - -- Marc Petit-Huguenin Email: marc-SHzPq5HBsP0vtAZ8OuFxWR2eb7JE58TQ&lt; at &gt;public.gmane.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRM7tOAAoJECnERZXWan7ENs8P+wdo8mIB+0HXQDVI7KNKa2d4 iGxgNyrIbR53+gQum7n00LHjl0xP0hKuSa/INbCcWP7JY7EH1O5Z4VI4Bej4QRHA SlRc6MOrlB2c6Zjk/z/IxVeYQjXVhyKAejhRdlO9HzyKkF5BNnJHm6InQV/40J5s jGM7WiSXo0NzF2qXcVAcRf03UNPw5rGJtUQHSfY9u5ufjM89gi/a7/tuyoCgQMne zmQh0MUDF2hETth0XVXuM1W2mTeRsRN/DwLSrlvnF4jWDihDvrh6czvXWzvue1tf fzBiCeaj/j/eKiixODeSwSnlLqbuEodRVT0jPvqErAgzCLuoc6Ys8HboEQuQf/k9 h19uPeY9h4n/nTr8otZCt5jJUZbT6QPNyV8GNbT5yoaVXqrjEFzuyr9u567UcphJ 6vd+NOIzwT8y9PIrRdqC8bVGa1FhiYc3</pre> Marc Petit-Huguenin 2013-03-03T21:06:23 http://permalink.gmane.org/gmane.ietf.p2psip/2764 <pre>Hi all, You can find a first version of the agenda for Orlando at the end of this e-mail. Note that most updated version can always be found at: http://www.ietf.org/proceedings/86/agenda/agenda-86-p2psip If we missed any request or assigned a wrong slot, please let us know. Note that the presentation slots may change by +-5 min or so. </pre> Carlos Jesús Bernardos Cano 2013-02-27T18:45:14 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.p2psip