From p2psip-bounces@ietf.org Fri Jan 2 08:54:47 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384A228C0DE; Fri, 2 Jan 2009 08:54:47 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6419D28C0DE for ; Fri, 2 Jan 2009 08:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE9B+jfwhBGV for ; Fri, 2 Jan 2009 08:54:45 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 11AA13A6825 for ; Fri, 2 Jan 2009 08:54:44 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so3382047wag.5 for ; Fri, 02 Jan 2009 08:54:33 -0800 (PST) Received: by 10.114.234.13 with SMTP id g13mr11891277wah.64.1230915272971; Fri, 02 Jan 2009 08:54:32 -0800 (PST) Received: by 10.114.169.17 with HTTP; Fri, 2 Jan 2009 08:54:32 -0800 (PST) Message-ID: Date: Fri, 2 Jan 2009 11:54:32 -0500 From: "Bruce Lowekamp" To: hocs@itri.org.tw In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: p2psip@ietf.org, worldhocs@yahoo.com.tw Subject: Re: [P2PSIP] [SIPP2P] question about some tables definition in the draft RELOAD-Base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org T24gU3VuLCBEZWMgMjEsIDIwMDggYXQgMTA6MDUgQU0sICA8aG9jc0BpdHJpLm9yZy50dz4gd3Jv dGU6Cj4gRGVhciBCcnVjZSwKPgo+IFRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgYW5zd2VyLgo+ IFNvLCBpbiB0aGUgY2hvcmQgU2VjdGlvbiwgZG9lcyB0aGUgcm91dGluZyB0YWJsZSBhbmQgdGhl IGZpbmdlciB0YWJsZSBzdGFuZAo+IGZvciB0aGUgc2FtZSB0aGluZz8KClRoZSByb3V0aW5nIHRh YmxlIGluIGNob3JkIGlzIHRoZSB1bmlvbiBvZiB0aGUgbmVpZ2hib3IgdGFibGUgYW5kIHRoZQpm aW5nZXIgdGFibGUuICAodGhpcyBpcyBzdGF0ZWQgY2xlYXJseSBpbiB0aGUgbWVzc2FnZSBmbG93 IGV4YW1wbGUsCmJ1dCBJIHdpbGwgYWRkIHNvbWV0aGluZyB0byB0aGUgY2hvcmQgb3ZlcnZpZXcg c2VjdGlvbiB0aGF0IGNsZWFybHkKc3RhdGVzIHRoaXMuKQoKPiBCZXNpZGVzLCBOZWlnaGJvcmhv b2QgdGFibGUgYW5kIE5laWdoYm9yIHRhYmxlIGFsc28gbWVhbgo+IHRoZSBzYW1lIHRoaW5nIHdo aWNoIGNvbnRhaW5zIHRoZSAzIHBlZXJzIGJlZm9yZSB0aGlzIHBlZXIgYW5kIHRoZSAzIHBlZXJz Cj4gYWZ0ZXIgaXQgaW4gdGhlIERIVCByaW5nLiBBbSBJIHJpZ2h0Pwo+IEkgbm90ZWQgdGhhdCB0 aGUgdGVybSBvZiBOZWlnaGJvciB0YWJsZSBpcyBvbmx5IHVzZWQgaW4gc2VjdGlvbiAxMC43LjMK PiBTdGFiaWxpemF0aW9uLCBtb3N0IG9mIG90aGVyIHN1YnNlY3Rpb25zIGluIHRoZSBjaG9yZCBT ZWN0aW9uIHVzZSB0aGUgdGVybQo+IG9mIE5laWdoYm9yaG9vZCB0YWJsZS4KClRoZXkgbWVhbiB0 aGUgc2FtZSB0aGluZy4gIFRoZXJlIHNlZW0gdG8gYmUgYSBsb3Qgb2YgdXNlcyBvZiBib3RoCnRl cm1zLiAgSSdsbCBtYWtlIGEgcGFzcyB0byBzd2l0Y2ggdG8ganVzdCBvbmUuCgo+Cj4gSW4gYWRk aXRpb24sIEkgY2FuJ3QgY2FwdHVyZSB0aGUgbWVhbmluZyBhYm91dCBncm93aW5nIG9yIHNocmlu a2luZyB0aGUgc2l6ZQo+IG9mIGZpbmdlciB0YWJsZSBhZGRyZXNzZWQgaW4gc2VjdGlvbiAxMC43 LjMgU3RhYmlsaXphdGlvbi4gVGhlIHN0YXRlbWVudAo+IGFkZHJlc3NlcyBhcyBmb2xsb3dpbmcs Cj4KPiAiVG8gZGV0ZXJtaW5lIGlmIGl0cyBmaW5nZXIgdGFibGUgaXMgc3VmZmljaWVudGx5IGxh cmdlLCBvbmUgYW4gaG91ciB0aGUKPiBwZWVyIHNob3VsZCBwZXJmb3JtIGEgUHJvYmUgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgZ3Jvd2luZyBpdHMgZmluZ2VyIHRhYmxlIGJ5Cj4gZm91ciBlbnRyaWVz IHdvdWxkIHJlc3VsdCBpbiBpdCBsZWFybmluZyBhdCBsZWFzdCB0d28gcGVlcnMgdGhhdCBpdCBk b2VzIG5vdAo+IGFscmVhZHkgaGF2ZSBpbiBpdHMgbmVpZ2hib3IgdGFibGUuIElmIHNvLCB0aGVu IHRoZSBmaW5nZXIgdGFibGUgU0hPVUxEIGJlCj4gZ3Jvd24gYnkgZm91ciBlbnRyaWVzLiIKPgo+ IFdoaWNoIHBlZXJzIHNob3VsZCB0aGUgcGVlciBwZXJmb3JtIGEgUHJvYmUgdG8/Cj4gSSBkb24n dCB1bmRlcnN0YW5kIHdoeSBpdCBzYXkgImdyb3dpbmcgaXRzIGZpbmdlciB0YWJsZSBieSBmb3Vy IGVudHJpZXMKPiB3b3VsZCByZXN1bHQgaW4gaXQgbGVhcm5pbmcgYXQgbGVhc3QgdHdvIHBlZXJz IHRoYXQgaXQgZG9lcyBub3QgYWxyZWFkeSBoYXZlCj4gaW4gaXRzIG5laWdoYm9yIHRhYmxlIj8g V291bGQgeW91IHBsZWFzZSBleHBsYWluIG1vcmUgZGV0YWlsIGZvciBtZT8KPgoKVGhlIGZpbmdl ciB0YWJsZSBlbnRyaWVzIGFyZSBpbmRleGVkIGFzIGRlc2NyaWJlZCBpbiB0aGUgQ2hvcmQKb3Zl cnZpZXcgKHRoZSAxc3QgaGFsZndheSBhcm91bmQgdGhlIHJpbmcsIHRoZSAybmQgMS80dGggYXJv dW5kLCB0aGUKM3JkIDEvOHRoLCBldGMpLiAgVGhlIHBlZXIgc2VuZHMgcHJvYmVzIHRvIHRoZSBJ RHMgb2YgdGhlIG5leHQgZm91cgpwb3RlbnRpYWwgZmluZ2VyIHRhYmxlIGVudHJpZXMgKGlmIHlv dSdyZSBzdGFydGluZyB3aXRoIDE2IGVudHJpZXMsCnRoaXMgd291bGQgYmUgdGhlIDE3dGgtLTIw dGgpLiAgSWYgdGhvc2UgcHJvYmVzIHJldHVybiBwZWVycyB0aGF0IGFyZQpub3QgaW4gdGhlIG5l aWdoYm9yIHRhYmxlLCB0aGF0IG1lYW5zIHRoZSBvdmVybGF5IGlzIGJpZ2dlciAoaGFzIG1vcmUK cGVlcnMpIHRoYW4gYSAxNi1lbnRyeSBmaW5nZXIgdGFibGUgaXMgZGVzaWduZWQgdG8gc3VwcG9y dCwgc28gdGhlCnRhYmxlIHNob3VsZCBiZSBncm93bi4KCkJydWNlCgoKPiBUaGFua3MgYSBsb3Qg aW4gYWR2YW5jZS4KPgo+IEJSLAo+IEplZmZyZXkKPgo+Cj4KPgo+IC0tLS0tLS0tLS0tLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLS0tLS0tLS0tCj4+ICJCcnVjZSBMb3dla2FtcCIgPGJi bEBsb3dla2FtcC5uZXQ+IDIwMDgvMTIvMTgg5LiL5Y2IIDExOjM1OjAyIHdyb3RlOgo+Cj4g5pS2 5Lu25Lq6OiBob2NzQGl0cmkub3JnLnR3Cj4g5Ymv5pys5oqE6YCBOiBwMnBzaXBAaWV0Zi5vcmcs d29ybGRob2NzQHlhaG9vLmNvbS50dwo+Cj4g5Li75peoOiBSZTogW1AyUFNJUF0gW1NJUFAyUF0g cXVlc3Rpb24gYWJvdXQgc29tZSB0YWJsZXMgZGVmaW5pdGlvbiBpbiB0aGUgZHJhZnQKPiBSRUxP QUQtQmFzZQo+Cj4gSmVmZnJleSwKPgo+IEkgdGhpbmsgdGhlIHRlcm1pbm9sb2d5IGNvbmZ1c2lv biBjb21lcyBmcm9tIHRoZSB1c2Ugb2YgZ2VuZXJpYyB0ZXJtcwo+IGluIHRoZSBidWxrIG9mIHRo ZSBkcmFmdCwgYnV0IG1vcmUgY2hvcmQtZGVyaXZlZCB0ZXJtcyBpbiB0aGUgY2hvcmQKPiBzZWN0 aW9uLgo+Cj4gVGhlIGNvbm5lY3Rpb24gdGFibGUgYW5kIHJvdXRpbmcgdGFibGUgYXJlIGdlbmVy aWMgdGVybXMgZGVmaW5lZCBpbgo+IHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uIGFuZCB1c2VkIGlu IHRoZSBtYWpvcml0eSBvZiB0aGUgZHJhZnQuIEZpbmdlcgo+IHRhYmxlIGlzIGEgY2hvcmQtc3Bl Y2lmaWMgdGVybSBmb3Igcm91dGluZyB0YWJsZS4gTmVpZ2hib3Job29kIHRhYmxlCj4gaXMgYWxz byBhIGNob3JkLXNwZWNpZmljIHRlcm0gKGNhbGxlZCBsZWFmIHNldCBpbiBzb21lIG90aGVyCj4g YWxnb3JpdGhtcykuIEkgYmVsaWV2ZSBGaW5nZXIgVGFibGUgYW5kIE5laWdoYm9yaG9vZCBUYWJs ZSBhcmUgdXNlZAo+IG9ubHkgaW4gdGhlIENob3JkIHNlY3Rpb24uCj4KPiBIb3BlIHRoYXQgaGVs cHMuIFBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGVyZSBhcmUgc3BlY2lmaWMgYXJlYXMgb2YKPiBj b25mdXNpb24gd2hlcmUgd2UgY2FuIHdvcmsgdG8gY2xlYXIgdXAgdGhlIHRlcm1pbm9sb2d5Lgo+ Cj4gQnJ1Y2UKPgo+Cj4gT24gVGh1LCBEZWMgMTgsIDIwMDggYXQgMTI6NTkgQU0sIDxob2NzQGl0 cmkub3JnLnR3PiB3cm90ZToKPj4gRGVhciBzaXIsCj4+Cj4+IEkgYW0gc3R1ZHlpbmcgdGhlIHNl Y3Rpb24gMTAgQ2hvcmQgYWxnb3JpdGhtIGluIHRoZSBkcmFmdCBSRUxPQUQtQmFzZS4gQnV0Cj4+ IEkKPj4gYW0gY29uZnVzZWQgd2l0aCBzb21lIHRlcm1pbm9sb2d5LCBJIGRvbid0IGtub3cgaWYg aXQgaXMgdGhlCj4+IG5vbi1jb25zaXN0ZW5jeQo+PiBwcm9ibGVtIG9yIG5lZWQgdG8gYmUgZnVy dGhlciBkZWZpbmVkIGNsZWFybHkuCj4+IFRoZSB0ZXJtaW5vbG9naWVzIGNvbmZ1c2VkIHRvIG1l IGFyZSB2YXJpb3VzIHRhYmxlcyBwcmVzZW50ZWQgaW4gZGlmZmVyZW50Cj4+IHN1YnNlY3Rpb25z LCBsaWtlIFJvdXRpbmcgdGFibGUsIGZpbmdlciB0YWJsZSwgY29ubmVjdGlvbiB0YWJsZSwgbmVp Z2hib3IKPj4gdGFibGUsIGFuZCBuZWlnaGJvcmhvb2QgdGFibGUuIEFueW9uZSBjYW4gZGVmaW5l IHRoZW0gbW9yZSBjbGVhciBmb3IgbWUgc28KPj4gdGhhdCBJIGNhbiByZWFkIGl0IGVhc2lseS4K Pj4gVGhhbmtzIGluIGFkdmFuY2UuCj4+Cj4+IEJSLAo+PiBKZWZmcmV5Cj4+Cj4+IOacrOS/oeS7 tuWPr+iDveWMheWQq+W3peeglOmZouapn+Wvhuizh+ioiu+8jOmdnuaMh+WumuS5i+aUtuS7tuiA he+8jOiri+WLv+S9v+eUqOaIluaPremcsuacrOS/oeS7tuWFp+Wuue+8jOS4puiri+mKt+avgOat pOS/oeS7tuOAggo+PiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbi4gUGxlYXNlIGRvIG5vdCB1c2Ugb3IKPj4gZGlzY2xvc2UgaXQgaW4gYW55IHdheSBhbmQg ZGVsZXRlIGl0IGlmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZAo+PiByZWNpcGllbnQuCj4+Cj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IFAyUFNJ UCBtYWlsaW5nIGxpc3QKPj4gUDJQU0lQQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcDJwc2lwCj4+Cj4+Cj4KPiDmnKzkv6Hku7blj6/og73ljIXlkKvl t6XnoJTpmaLmqZ/lr4bos4foqIrvvIzpnZ7mjIflrprkuYvmlLbku7bogIXvvIzoq4vli7/kvb/n lKjmiJbmj63pnLLmnKzkv6Hku7blhaflrrnvvIzkuKboq4vpirfmr4DmraTkv6Hku7bjgIIKPiBU aGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gUGxlYXNlIGRv IG5vdCB1c2Ugb3IKPiBkaXNjbG9zZSBpdCBpbiBhbnkgd2F5IGFuZCBkZWxldGUgaXQgaWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudC4KPgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpQMlBTSVAgbWFpbGluZyBsaXN0ClAyUFNJUEBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcAo= From p2psip-bounces@ietf.org Fri Jan 2 10:37:49 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26283A6837; Fri, 2 Jan 2009 10:37:48 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061C83A68D0 for ; Fri, 2 Jan 2009 10:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofrYGtp3utUb for ; Fri, 2 Jan 2009 10:37:46 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 9960A3A6965 for ; Fri, 2 Jan 2009 10:36:14 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so5823840rvf.49 for ; Fri, 02 Jan 2009 10:36:01 -0800 (PST) Received: by 10.114.81.1 with SMTP id e1mr11939626wab.136.1230921361415; Fri, 02 Jan 2009 10:36:01 -0800 (PST) Received: by 10.114.169.17 with HTTP; Fri, 2 Jan 2009 10:36:01 -0800 (PST) Message-ID: Date: Fri, 2 Jan 2009 13:36:01 -0500 From: "Bruce Lowekamp" To: "Antoine Roly" In-Reply-To: <493c07310812230827i5bd24035u5fcdb7ecb0f6700f@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <493c07310812230827i5bd24035u5fcdb7ecb0f6700f@mail.gmail.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] questions about storage section X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org On Tue, Dec 23, 2008 at 11:27 AM, Antoine Roly wrote: > Hi, > > I have some questions about storage section in the Reload Base draft: > > Section 6 > > storage_time: The time when the data was stored in absolute time, > represented in seconds since the Unix epoch. Any attempt to store a data > value with a storage time before that of a value already stored at this > location MUST generate a 412 error. Note that this does not require > synchronized clocks: the receiving peer uses the storage time in the > previous store, not its own clock. > > What value should be used for the first store a peer receive? For the next > requests, if I'm right, the peer starts a timer every time it receives a > store, and set storage time value to [previous storage time + timer value], > isn't it? > The storage_time is set by the node generating the store request. All the receiving peer needs to do is compare the storage_time in the new request with the one in the old. I am personally not convinced that this field adds anything to the protocol not already accomplished by the generation id, but haven't taken the time to evalaute it fully. It makes a system with multiple writers for the same value much harder. > Section 6.3.1.1 Store request definition: > > kind: The Kind-ID. Implementations SHOULD reject requests corresponding to > unknown kinds unless specifically configured otherwise. > > but a few sentences below: > > The peer MUST perform the following checks: > o The kind_id is known and supported. > [...] > If all these checks succeed, the peer MUST attempt to store the data values > [...] > > What is the correct action if I am configured to accept unknown kinds? What that means is outside the scope of the draft because the security policy for each kind varies. (but see the separate threads on agnostic or dynamic new kinds) > > For non-replica stores, if the store succeeds and the data is changed, then > the peer must increase the generation counter by at least one. If there are > multiple stored values in a single StoreKindData, it is permissible for the > peer to increase the generation counter by only 1 for the entire Kind-ID, or > by 1 or more than one for each value. > > Why allowing to increase the counter by more than one? If a node increase > the value by more than one, it could become higher than the number of time > the object has been written (which is the definition of generation_counter). > I'm not really sure why the "or more than one" is there. I don't think it would hurt the correctness, but I don't know of a reason to do it. > 0 is used by other nodes (note: which other nodes?) to indicate that they > are indifferent to the generation counter's current value. For replica > Stores, the peer MUST set the generation counter to match the > generation_counter in the message. Replica Stores MUST NOT use a generation > counter of 0. > > If I am a node indifferent to generation counter's value and I Store data, I > can set generation value to 0. What value should be used for replicas Stores > since they must no use 0? > That text is pretty unclear/wrong. "other nodes" means that it's possible for a store to say "replace the current value with this regardless of generation". Later on "in the message" should say "stored by the responsible peer." I will make a note to change. Bruce > Best regards, > > A. > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 2 11:32:00 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260183A6805; Fri, 2 Jan 2009 11:32:00 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED7C3A6805 for ; Fri, 2 Jan 2009 11:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1iwayjeWy6u for ; Fri, 2 Jan 2009 11:31:57 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 57A853A67A1 for ; Fri, 2 Jan 2009 11:31:57 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so3415961wag.5 for ; Fri, 02 Jan 2009 11:31:43 -0800 (PST) Received: by 10.115.32.18 with SMTP id k18mr11972891waj.98.1230924703669; Fri, 02 Jan 2009 11:31:43 -0800 (PST) Received: by 10.114.169.17 with HTTP; Fri, 2 Jan 2009 11:31:43 -0800 (PST) Message-ID: Date: Fri, 2 Jan 2009 14:31:43 -0500 From: "Bruce Lowekamp" To: "Antoine Roly" In-Reply-To: <493c07310812040610i1befab07w913f5ccdb0f3ace@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <493c07310812040610i1befab07w913f5ccdb0f3ace@mail.gmail.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] questions about reload draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Antoine, Sorry to take so long to respond to this. Responses below: On Thu, Dec 4, 2008 at 9:10 AM, Antoine Roly wrote: > Hi, > > I have some questions about the draft Reload-Base: > > - Usage of Probes before Attaches: in section 10.5, the > point 2 is "JP uses a series of Probes to populate its routing > table." but in section 3.5.2 and callflows in section 12 there is no > Probe message. I know Section 10 is specific for Chord-Reload, and > section 3.5.2 is generic, but as it is currently described, it is > not clear if Probes should be really used or not. Is Probe useful > just only when using Chord? If yes, I assume these Probes are sent > with an empty list of info, and so, should'nt Ping be used instead? > Section 12 should show at least one Probe. The Probes are useful so that the new peer knows which peers to send its Attach requests to. (you could, in theory, do a lot without them, but there are various problems with that, such as sending multiple attaches to the same peer when it will fill multiple entries in your finger table) Probes are intended for be extensible by the overlay algorithm, although the Chord in Section 10 doesn't make use of that feature. Probe is likely to be more useful for other overlay algorithms. In chord you could replace several of the Probes with Ping, but they're intended for separate purposes, and I think it's better to be consistent doing overlay maintentance with the same method, even though Chord doesn't do much with the contents of Probe. > - Could you clarify point 10.6 on source routing? It is said that > source-routing Attaches through the peer from which a node learned > the new peer's Node-ID "allows the overlay to recover from > instability". This latest statement probably requires a more detailed > explanation. Additional question: why is the source-routing of > Attaches mandatory ONLY for peer in the neighborhood's table. If the > peer crashes, I assume Attaches are routed "conventionally" > through the overlay. > If you learn about peer C from peer B, you know peer B can reach peer C. If the overlay is unstable, you may not be able to reach peer C directly. Therefore source routing through B will allow the overlay to stabilize (at least by adding C). Finger table entries are an optimization. The correctness of the overlay is ultimately dependent on the successor entries being correct. Therefore, more effort is expended to make the neighborhood correct than for the finger table entries (which will ultimately be corrected, anyway) > - Must we add a byte "on the wire" just before ResourceId (as > described in section 5.2.1.1) or even before every structure of > variable length? If we must add one before every structure of > variable length, why not explicitly include it while describing the > message fields? For example, for the payload length, since the > signature has a variable length, it seems necessary to explicitely > add a 3 bytes message field representing the length before the > payload, isn't it? > I'm not sure what you're asking here. The benefit of defining types in one place is that we don't need to break out every element of that type for every message it's used in. Some payloads are fixed-length. > - section 10.7.3: "To determine if its finger table is sufficiently > large, one an hour the peer should perform a Probe to determine > whether growing its finger table by four entries would result in it > learning at least two peers that it does not already have in its > neighbor table.". This last sentence is not easy to follow: to which > node should the Probe be addressed? (By the way, it could maybe be > a Ping too). > I just answered this question in another thread. I will try to add an example to that text. Bruce > Thanks > > Antoine > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jan 4 13:03:13 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2B93A6831; Sun, 4 Jan 2009 13:03:13 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3043A6861 for ; Sun, 4 Jan 2009 13:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCnLXEaO46TH for ; Sun, 4 Jan 2009 13:03:10 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 9D4223A6813 for ; Sun, 4 Jan 2009 13:03:10 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so3769437wag.5 for ; Sun, 04 Jan 2009 13:02:57 -0800 (PST) Received: by 10.114.122.5 with SMTP id u5mr13329825wac.88.1231102977040; Sun, 04 Jan 2009 13:02:57 -0800 (PST) Received: by 10.114.169.17 with HTTP; Sun, 4 Jan 2009 13:02:57 -0800 (PST) Message-ID: Date: Sun, 4 Jan 2009 16:02:57 -0500 From: "Bruce Lowekamp" To: "David A. Bryan" In-Reply-To: <8b2769930812261413p55989ea7gce3ee5df760aeda3@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <8b2769930812260708w5d97d5aelefefcb0bb2826316@mail.gmail.com> <8b2769930812261413p55989ea7gce3ee5df760aeda3@mail.gmail.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org I've been in favor of adoption, and I am not going to change my opinion now. However, I have some serious concerns about this draft, and the revisions have not addressed them. When the revision was posted, it should have been announced on the list and the changes made to it brought to the attention of the wg members for discussion. I have technical concerns with this draft that have been mentioned before (OWD can't be measured the way this draft proposes, and I don't believe the multiple-responses-for-an-echo-request technique should be supported). There are also some issues with duplication of functionality between base methods and the new methods defined. I think this is something we can address later as a working group. I don't understand why the "diagnostic server" material was added to this revision. I think it should be removed. If something like this is desired, it should be entirely separate. Bruce On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan wrote: > Looking for objections, since we had consensus in the room in Minneapolis. > > Thanks for clarifying! > > David (as chair) > > On Fri, Dec 26, 2008 at 3:49 PM, Dan York wrote: >> David, >> >> Are you expecting us to send messages to the list agreeing with this? Or >> are you taking the lack of *dissenting* messages as a sign of consensus? >> >> Dan >> >> P.S. I agree with this action, by the way, and did hum to adopt in the room >> in Minneapolis. >> >> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >> >>> In Minneapolis, there was a hum taken which indicated rough consensus >>> to move towards adopting the P2PSIP diagnostics draft as a working >>> group item. Since there were also a number of corrections/changes >>> requested, the chairs asked the authors to iterate the draft and post >>> it, and then we would verify the consensus on list. >>> >>> The authors posted the revisions to the draft a few weeks ago: >>> >>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>> >>> I'd like to ask for list consensus to verify the consensus from the >>> meeting in favor of adopting this work as a WG item. >>> >>> David (as chair) >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> -- >> Dan York, CISSP, Director of Emerging Communication Technology >> Office of the CTO Voxeo Corporation dyork@voxeo.com >> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >> >> Build voice applications based on open standards. >> Find out how at http://www.voxeo.com/free >> >> >> >> >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jan 4 14:23:18 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701593A6934; Sun, 4 Jan 2009 14:23:18 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129AF3A6934 for ; Sun, 4 Jan 2009 14:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyadvt4dID4c for ; Sun, 4 Jan 2009 14:23:13 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id DB15C3A689F for ; Sun, 4 Jan 2009 14:23:12 -0800 (PST) Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n04MLswo004201; Sun, 4 Jan 2009 17:21:54 -0500 (EST) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n04MLsoZ018504; Sun, 4 Jan 2009 17:21:54 -0500 (EST) Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.3/8.14.1/Submit) with ESMTP id n04MLr0i018501; Sun, 4 Jan 2009 17:21:54 -0500 (EST) X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs Date: Sun, 4 Jan 2009 17:21:53 -0500 (EST) From: Salman Abdul Baset To: Bruce Lowekamp In-Reply-To: Message-ID: References: <8b2769930812260708w5d97d5aelefefcb0bb2826316@mail.gmail.com> <8b2769930812261413p55989ea7gce3ee5df760aeda3@mail.gmail.com> User-Agent: Alpine 1.00 (SOC 882 2007-12-20) MIME-Version: 1.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org I agree with Bruce. In addition: Diagnostics are a combination of techniques. The methods specified in the draft are one of them. They may well be other approaches such as state acquisition of a node and overlay crawl through overlay operator managed nodes. A node regularly needs to perform overlay maintenance operations. It may need to be specified when does a node switch to a 'diagnostic mode'. An overlay operator may be interested in gathering a 'health report' of the overlay. When the overlay size is 'small', such information can easily be overlayed on a geographical map (we used this approach in our OpenVoIP system). Diagnostics may play a role here. As a procedural comment, I think the diagnostic document track should be 'Experimental' or 'Informational' until we have gained sufficient understanding of the protocol methods and required information from practical deployments. -salman On Sun, 4 Jan 2009, Bruce Lowekamp wrote: > I've been in favor of adoption, and I am not going to change my opinion now. > > However, I have some serious concerns about this draft, and the > revisions have not addressed them. When the revision was posted, it > should have been announced on the list and the changes made to it > brought to the attention of the wg members for discussion. > > I have technical concerns with this draft that have been mentioned > before (OWD can't be measured the way this draft proposes, and I don't > believe the multiple-responses-for-an-echo-request technique should be > supported). > > There are also some issues with duplication of functionality between > base methods and the new methods defined. I think this is something > we can address later as a working group. > > I don't understand why the "diagnostic server" material was added to > this revision. I think it should be removed. If something like this > is desired, it should be entirely separate. > > Bruce > > > > > On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan wrote: >> Looking for objections, since we had consensus in the room in Minneapolis. >> >> Thanks for clarifying! >> >> David (as chair) >> >> On Fri, Dec 26, 2008 at 3:49 PM, Dan York wrote: >>> David, >>> >>> Are you expecting us to send messages to the list agreeing with this? Or >>> are you taking the lack of *dissenting* messages as a sign of consensus? >>> >>> Dan >>> >>> P.S. I agree with this action, by the way, and did hum to adopt in the room >>> in Minneapolis. >>> >>> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >>> >>>> In Minneapolis, there was a hum taken which indicated rough consensus >>>> to move towards adopting the P2PSIP diagnostics draft as a working >>>> group item. Since there were also a number of corrections/changes >>>> requested, the chairs asked the authors to iterate the draft and post >>>> it, and then we would verify the consensus on list. >>>> >>>> The authors posted the revisions to the draft a few weeks ago: >>>> >>>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>>> >>>> I'd like to ask for list consensus to verify the consensus from the >>>> meeting in favor of adopting this work as a WG item. >>>> >>>> David (as chair) >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> -- >>> Dan York, CISSP, Director of Emerging Communication Technology >>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>> >>> Build voice applications based on open standards. >>> Find out how at http://www.voxeo.com/free >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jan 4 22:17:50 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816E23A6A94; Sun, 4 Jan 2009 22:17:50 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773223A6A94 for ; Sun, 4 Jan 2009 22:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuoCeSfyq-qu for ; Sun, 4 Jan 2009 22:17:48 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 192AC3A6837 for ; Sun, 4 Jan 2009 22:17:47 -0800 (PST) Received: by fxm13 with SMTP id 13so1404583fxm.13 for ; Sun, 04 Jan 2009 22:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language :message-id; bh=NFTzelGUKFdBKXoaw9+lMPbTDaNt7xQ4EUX8DR3aS4g=; b=pbVwIUKAkMjGlEM3ADxPj+P8geMQ9/gwQbj4+YZJbH1hdYcbypwtNB1LjJAONff3f7 tbOV5sqBmc6qdTQvur0dUuMuKpbRni5bOJpoMf5V7ILGgyOPRvVYdqX9KGsBC3WzDgo/ oQnGge5fBUP3HCUxjO4G52ZhJ3dvZyYOpwgWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:message-id; b=YrxkzfES9FZ/WTlUGHW+C9xpVs/joZ5esfXNLB9HJPKi7ConTZMHLX1Raxi/LQS4Y/ wHhZN89rrM5nDX9VGb6sMcOfkrIFrInWixryjlBWiPFk7L52usoJPhk0vA99NR1elE/Z 4MxMtN91N2j2zgiSil9tSK/u0UQpWXIbXmRus= Received: by 10.103.170.6 with SMTP id x6mr7263414muo.13.1231136254503; Sun, 04 Jan 2009 22:17:34 -0800 (PST) Received: from windows8d787f9 (bzq-79-177-0-249.red.bezeqint.net [79.177.0.249]) by mx.google.com with ESMTPS id u26sm44463654mug.26.2009.01.04.22.17.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Jan 2009 22:17:33 -0800 (PST) From: "Roni Even" To: "'Bruce Lowekamp'" , "'David A. Bryan'" References: <8b2769930812260708w5d97d5aelefefcb0bb2826316@mail.gmail.com> <8b2769930812261413p55989ea7gce3ee5df760aeda3@mail.gmail.com> In-Reply-To: Date: Mon, 5 Jan 2009 08:16:37 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aclur/EYenLoOGVlQXuBV6LuEc9XmgATHegA Content-language: en-us Message-ID: <4961a5fd.1ade660a.7498.17b3@mx.google.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Hi Bruce, I agree with you about that we need to address any duplication between the base draft and this draft. The consensus in the last meeting was to define separate methods in the diagnostics draft and leave the ones in the base draft simple. As for the parameters in diagnostics information there was some discussion in the past on the list and I also think we need to look at them. Regards Roni Even -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Bruce Lowekamp Sent: Sunday, January 04, 2009 11:03 PM To: David A. Bryan Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item I've been in favor of adoption, and I am not going to change my opinion now. However, I have some serious concerns about this draft, and the revisions have not addressed them. When the revision was posted, it should have been announced on the list and the changes made to it brought to the attention of the wg members for discussion. I have technical concerns with this draft that have been mentioned before (OWD can't be measured the way this draft proposes, and I don't believe the multiple-responses-for-an-echo-request technique should be supported). There are also some issues with duplication of functionality between base methods and the new methods defined. I think this is something we can address later as a working group. I don't understand why the "diagnostic server" material was added to this revision. I think it should be removed. If something like this is desired, it should be entirely separate. Bruce On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan wrote: > Looking for objections, since we had consensus in the room in Minneapolis. > > Thanks for clarifying! > > David (as chair) > > On Fri, Dec 26, 2008 at 3:49 PM, Dan York wrote: >> David, >> >> Are you expecting us to send messages to the list agreeing with this? Or >> are you taking the lack of *dissenting* messages as a sign of consensus? >> >> Dan >> >> P.S. I agree with this action, by the way, and did hum to adopt in the room >> in Minneapolis. >> >> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >> >>> In Minneapolis, there was a hum taken which indicated rough consensus >>> to move towards adopting the P2PSIP diagnostics draft as a working >>> group item. Since there were also a number of corrections/changes >>> requested, the chairs asked the authors to iterate the draft and post >>> it, and then we would verify the consensus on list. >>> >>> The authors posted the revisions to the draft a few weeks ago: >>> >>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>> >>> I'd like to ask for list consensus to verify the consensus from the >>> meeting in favor of adopting this work as a WG item. >>> >>> David (as chair) >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> -- >> Dan York, CISSP, Director of Emerging Communication Technology >> Office of the CTO Voxeo Corporation dyork@voxeo.com >> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >> >> Build voice applications based on open standards. >> Find out how at http://www.voxeo.com/free >> >> >> >> >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jan 5 18:16:33 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC553A690E; Mon, 5 Jan 2009 18:16:33 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A1B3A68DA for ; Mon, 5 Jan 2009 18:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.484 X-Spam-Level: X-Spam-Status: No, score=-103.484 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQHIuvCoQV8x for ; Mon, 5 Jan 2009 18:16:25 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 449943A689D for ; Mon, 5 Jan 2009 18:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1231208172; x=1262744172; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20Roni=20Even=20,=20"'Bruce=20Lo wekamp'"=20,=0D=0A=20=20=20=20=20=20=20 =20"'David=20A.=20Bryan'"=20|CC:=20" p2psip@ietf.org"=20|Date:=20Mon,=205=20J an=202009=2018:15:50=20-0800|Subject:=20RE:=20[P2PSIP]=20 List=20consensus=20call=20to=09adopt=0D=0A=09draft-zheng- p2psip-diagnose-04=20as=20a=20WG=20item|Thread-Topic:=20[ P2PSIP]=20List=20consensus=20call=20to=09adopt=0D=0A=09dr aft-zheng-p2psip-diagnose-04=20as=20a=20WG=20item |Thread-Index:=20Aclur/EYenLoOGVlQXuBV6LuEc9XmgATHegAACmK pJA=3D|Message-ID:=20<2D06DE445C2ADE44890118C3F449B96321B 5C433@NASANEXMB12.na.qualcomm.com>|References:=20<8b27699 30812260708w5d97d5aelefefcb0bb2826316@mail.gmail.com>=0D =0A=09=0D =0A=09<8b2769930812261413p55989ea7gce3ee5df760aeda3@mail. gmail.com>=0D=0A=09=0D=0A=20<4961a5fd.1ade660a.7498.1 7b3@mx.google.com>|In-Reply-To:=20<4961a5fd.1ade660a.7498 .17b3@mx.google.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 100,188,5486"=3B=20a=3D"14377647"; bh=1TxlsBKp2E9ou/OhD4qJfQy35waSEXWRO848VUu0ExU=; b=S0S5p32P+nWTJtJMY1gr52rvrlD/FH1HD+4sqCYtJr8vgmYFsoKDj2J8 3J1KVLo6pBXnzIJIV8Wml4spv2Ccrkj/3x05q+doV7WT8hBYwe6IGkdCV lSLc3jvw3jAtPXwd2s4C8ri8FXlIUCGcIrXcnwff+HSOJHUJRX5PoS0xh M=; X-IronPort-AV: E=McAfee;i="5100,188,5486"; a="14377647" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jan 2009 18:16:10 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n062GAlY026401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Jan 2009 18:16:10 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n062FrIV024235 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Jan 2009 18:15:53 -0800 (PST) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.33]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Mon, 5 Jan 2009 18:15:52 -0800 From: "Das, Saumitra" To: Roni Even , "'Bruce Lowekamp'" , "'David A. Bryan'" Date: Mon, 5 Jan 2009 18:15:50 -0800 Thread-Topic: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item Thread-Index: Aclur/EYenLoOGVlQXuBV6LuEc9XmgATHegAACmKpJA= Message-ID: <2D06DE445C2ADE44890118C3F449B96321B5C433@NASANEXMB12.na.qualcomm.com> References: <8b2769930812260708w5d97d5aelefefcb0bb2826316@mail.gmail.com> <8b2769930812261413p55989ea7gce3ee5df760aeda3@mail.gmail.com> <4961a5fd.1ade660a.7498.17b3@mx.google.com> In-Reply-To: <4961a5fd.1ade660a.7498.17b3@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org I agree with Bruce that this needs work. I have the following comments 1. Why does the introduction of the draft specifically target p2p service providers crawling the overlay for diagnostic information. We should be trying to develop a general mechanism to diagnose nodes and links between nodes. Whether this is used by the service provider or between two nodes in the p2p overlay is not important. An overlay node may use diagnosis to detect problems, make choices etc. 2. We need a way for the p2p overlay operator to cause diagnosis between nodes in the overlay and not just retrieve information about the node itself. For example, the operator may wish to figure out the latencies observed between superpeers in the overlay to make a usage specific optimization 3. Some of the items discussed on the list are not reflected in the document specifically the discussions on node specific metrics like cpu and bw. We should look at what has been useful for PlanetLab in this context since it is a long running overlay. The node metrics are routinely used in planetlab by overlay deployers. 4. The diagnostic server should be out of scope for this draft. Rather we should think about a mechanism for the overlay operator/(maybe the enrollment server or some other entity) to trigger a specific diagnosis between two overlay nodes. What is done with the diagnostic information obtained need not be standardized atleast in this draft. Thanks Saumitra www.saumitra.info -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, January 04, 2009 10:17 PM To: 'Bruce Lowekamp'; 'David A. Bryan' Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item Hi Bruce, I agree with you about that we need to address any duplication between the base draft and this draft. The consensus in the last meeting was to define separate methods in the diagnostics draft and leave the ones in the base draft simple. As for the parameters in diagnostics information there was some discussion in the past on the list and I also think we need to look at them. Regards Roni Even -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Bruce Lowekamp Sent: Sunday, January 04, 2009 11:03 PM To: David A. Bryan Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item I've been in favor of adoption, and I am not going to change my opinion now. However, I have some serious concerns about this draft, and the revisions have not addressed them. When the revision was posted, it should have been announced on the list and the changes made to it brought to the attention of the wg members for discussion. I have technical concerns with this draft that have been mentioned before (OWD can't be measured the way this draft proposes, and I don't believe the multiple-responses-for-an-echo-request technique should be supported). There are also some issues with duplication of functionality between base methods and the new methods defined. I think this is something we can address later as a working group. I don't understand why the "diagnostic server" material was added to this revision. I think it should be removed. If something like this is desired, it should be entirely separate. Bruce On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan wrote: > Looking for objections, since we had consensus in the room in Minneapolis. > > Thanks for clarifying! > > David (as chair) > > On Fri, Dec 26, 2008 at 3:49 PM, Dan York wrote: >> David, >> >> Are you expecting us to send messages to the list agreeing with this? Or >> are you taking the lack of *dissenting* messages as a sign of consensus? >> >> Dan >> >> P.S. I agree with this action, by the way, and did hum to adopt in the room >> in Minneapolis. >> >> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >> >>> In Minneapolis, there was a hum taken which indicated rough consensus >>> to move towards adopting the P2PSIP diagnostics draft as a working >>> group item. Since there were also a number of corrections/changes >>> requested, the chairs asked the authors to iterate the draft and post >>> it, and then we would verify the consensus on list. >>> >>> The authors posted the revisions to the draft a few weeks ago: >>> >>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>> >>> I'd like to ask for list consensus to verify the consensus from the >>> meeting in favor of adopting this work as a WG item. >>> >>> David (as chair) >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> -- >> Dan York, CISSP, Director of Emerging Communication Technology >> Office of the CTO Voxeo Corporation dyork@voxeo.com >> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >> >> Build voice applications based on open standards. >> Find out how at http://www.voxeo.com/free >> >> >> >> >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jan 5 18:34:39 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CAB83A6856; Mon, 5 Jan 2009 18:34:39 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771BC3A6856 for ; Mon, 5 Jan 2009 18:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9htRGlVyHo8 for ; Mon, 5 Jan 2009 18:34:37 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CB3FD3A6835 for ; Mon, 5 Jan 2009 18:34:36 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD100A6J35A6C@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 10:34:22 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD1003B535AAR@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 10:34:22 +0800 (CST) Received: from s64081 ([10.164.12.60]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD100NNP35949@szxml05-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 10:34:22 +0800 (CST) Date: Tue, 06 Jan 2009 10:34:21 +0800 From: Song Haibin In-reply-to: To: 'Salman Abdul Baset' , 'Bruce Lowekamp' Message-id: <009001c96fa7$485a7880$3c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcluuwgQZ8E9MoaQTE6ponAhGo74lgA4jO7Q Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adoptdraft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Hi Salman, >-----Original Message----- >From: Salman Abdul Baset >Sent: Monday, January 05, 2009 6:22 AM >I agree with Bruce. In addition: > >Diagnostics are a combination of techniques. The methods specified in the >draft are one of them. They may well be other approaches such as state >acquisition of a node and overlay crawl through overlay operator managed >nodes. It is true if you have operator managed nodes, just as we did in our early SEP prototype. However, the methods defined in the diagnostics draft can accommodate different scenarios. E.g. you can use the Echo method defined in the diagnostics draft with the destination list set to a list of overlay managed nodes to retrieve the diagnostic information of them (or use the Path_Track iteratively) and only accept the Echo responses from the authorized nodes. >A node regularly needs to perform overlay maintenance operations. >It may need to be specified when does a node switch to a 'diagnostic mode'. I agree what you mentioned here is needed. IMHO, it is related to the usage scenarios of the diagnostics, especially that when does a node need to perform diagnostic operation. The diagnostic operation may be generated from the operator (that is part of the reason why we optionally need a diagnostic server) or from an overlay node itself due to some connectivity problem or other reasons. >An overlay operator may be interested in gathering a 'health report' of >the overlay. When the overlay size is 'small', such information can easily >be overlayed on a geographical map (we used this approach in our OpenVoIP >system). Diagnostics may play a role here. Yes, I agree that diagnostics can be used to gather proper information and do the connectivity monitoring for such a "health report". By the way, some coordinate system or an ALTO server can be used for building your geographical map. >As a procedural comment, I think the diagnostic document track should be >'Experimental' or 'Informational' until we have gained sufficient >understanding of the protocol methods and required information from >practical deployments. IMO, it will be "standard track", although it is not perfect at the moment, we still have a lot of work to do until we output the final revision. BR Haibin >-salman > > >On Sun, 4 Jan 2009, Bruce Lowekamp wrote: > >> I've been in favor of adoption, and I am not going to change my opinion now. >> >> However, I have some serious concerns about this draft, and the >> revisions have not addressed them. When the revision was posted, it >> should have been announced on the list and the changes made to it >> brought to the attention of the wg members for discussion. >> >> I have technical concerns with this draft that have been mentioned >> before (OWD can't be measured the way this draft proposes, and I don't >> believe the multiple-responses-for-an-echo-request technique should be >> supported). >> >> There are also some issues with duplication of functionality between >> base methods and the new methods defined. I think this is something >> we can address later as a working group. >> >> I don't understand why the "diagnostic server" material was added to >> this revision. I think it should be removed. If something like this >> is desired, it should be entirely separate. >> >> Bruce >> >> >> >> >> On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan wrote: >>> Looking for objections, since we had consensus in the room in Minneapolis. >>> >>> Thanks for clarifying! >>> >>> David (as chair) >>> >>> On Fri, Dec 26, 2008 at 3:49 PM, Dan York wrote: >>>> David, >>>> >>>> Are you expecting us to send messages to the list agreeing with this? Or >>>> are you taking the lack of *dissenting* messages as a sign of consensus? >>>> >>>> Dan >>>> >>>> P.S. I agree with this action, by the way, and did hum to adopt in the room >>>> in Minneapolis. >>>> >>>> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >>>> >>>>> In Minneapolis, there was a hum taken which indicated rough consensus >>>>> to move towards adopting the P2PSIP diagnostics draft as a working >>>>> group item. Since there were also a number of corrections/changes >>>>> requested, the chairs asked the authors to iterate the draft and post >>>>> it, and then we would verify the consensus on list. >>>>> >>>>> The authors posted the revisions to the draft a few weeks ago: >>>>> >>>>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>>>> >>>>> I'd like to ask for list consensus to verify the consensus from the >>>>> meeting in favor of adopting this work as a WG item. >>>>> >>>>> David (as chair) >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> -- >>>> Dan York, CISSP, Director of Emerging Communication Technology >>>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>>> >>>> Build voice applications based on open standards. >>>> Find out how at http://www.voxeo.com/free >>>> >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jan 5 18:53:34 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB1D3A68B3; Mon, 5 Jan 2009 18:53:33 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E5F3A68B3 for ; Mon, 5 Jan 2009 18:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KUYgW62hABE for ; Mon, 5 Jan 2009 18:53:31 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 057F63A689D for ; Mon, 5 Jan 2009 18:53:31 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD1002CN3Z605@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 10:52:18 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD1001P03Z6V5@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 10:52:18 +0800 (CST) Received: from s64081 ([10.164.12.60]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD10035H3Z57Q@szxml05-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 10:52:18 +0800 (CST) Date: Tue, 06 Jan 2009 10:52:17 +0800 From: Song Haibin In-reply-to: <2D06DE445C2ADE44890118C3F449B96321B5C433@NASANEXMB12.na.qualcomm.com> To: "'Das, Saumitra'" Message-id: <009101c96fa9$c9c6e0a0$3c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Aclur/EYenLoOGVlQXuBV6LuEc9XmgATHegAACmKpJAAAYdvEA== Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adoptdraft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Hi Das, Thank you for your response. The method Inspect is defined for the purpose of (1) and (2). And because of limited time, we could take more time to look at the parameters you mentioned in (3) such as bw and cpu later as a workgroup item. Best Regards, Haibin Email: melodysong@huawei.com Skype: alexsonghw >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >Das, Saumitra >Sent: Tuesday, January 06, 2009 10:16 AM >To: Roni Even; 'Bruce Lowekamp'; 'David A. Bryan' >Cc: p2psip@ietf.org >Subject: Re: [P2PSIP] List consensus call to >adoptdraft-zheng-p2psip-diagnose-04 as a WG item > >I agree with Bruce that this needs work. I have the following comments > >1. Why does the introduction of the draft specifically target p2p service >providers crawling the overlay for diagnostic information. We should be trying >to develop a general mechanism to diagnose nodes and links between nodes. Whether >this is used by the service provider or between two nodes in the p2p overlay >is not important. An overlay node may use diagnosis to detect problems, make >choices etc. > >2. We need a way for the p2p overlay operator to cause diagnosis between nodes >in the overlay and not just retrieve information about the node itself. For >example, the operator may wish to figure out the latencies observed between >superpeers in the overlay to make a usage specific optimization > >3. Some of the items discussed on the list are not reflected in the document >specifically the discussions on node specific metrics like cpu and bw. We should >look at what has been useful for PlanetLab in this context since it is a long >running overlay. The node metrics are routinely used in planetlab by overlay >deployers. > >4. The diagnostic server should be out of scope for this draft. Rather we should >think about a mechanism for the overlay operator/(maybe the enrollment server >or some other entity) to trigger a specific diagnosis between two overlay nodes. >What is done with the diagnostic information obtained need not be standardized >atleast in this draft. > >Thanks >Saumitra > >www.saumitra.info > >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >Roni Even >Sent: Sunday, January 04, 2009 10:17 PM >To: 'Bruce Lowekamp'; 'David A. Bryan' >Cc: p2psip@ietf.org >Subject: Re: [P2PSIP] List consensus call to adopt >draft-zheng-p2psip-diagnose-04 as a WG item > >Hi Bruce, > >I agree with you about that we need to address any duplication between the >base draft and this draft. The consensus in the last meeting was to define >separate methods in the diagnostics draft and leave the ones in the base >draft simple. > >As for the parameters in diagnostics information there was some discussion >in the past on the list and I also think we need to look at them. > >Regards >Roni Even > >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >Bruce Lowekamp >Sent: Sunday, January 04, 2009 11:03 PM >To: David A. Bryan >Cc: p2psip@ietf.org >Subject: Re: [P2PSIP] List consensus call to adopt >draft-zheng-p2psip-diagnose-04 as a WG item > >I've been in favor of adoption, and I am not going to change my opinion now. > >However, I have some serious concerns about this draft, and the >revisions have not addressed them. When the revision was posted, it >should have been announced on the list and the changes made to it >brought to the attention of the wg members for discussion. > >I have technical concerns with this draft that have been mentioned >before (OWD can't be measured the way this draft proposes, and I don't >believe the multiple-responses-for-an-echo-request technique should be >supported). > >There are also some issues with duplication of functionality between >base methods and the new methods defined. I think this is something >we can address later as a working group. > >I don't understand why the "diagnostic server" material was added to >this revision. I think it should be removed. If something like this >is desired, it should be entirely separate. > >Bruce > > > > >On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan wrote: >> Looking for objections, since we had consensus in the room in Minneapolis. >> >> Thanks for clarifying! >> >> David (as chair) >> >> On Fri, Dec 26, 2008 at 3:49 PM, Dan York wrote: >>> David, >>> >>> Are you expecting us to send messages to the list agreeing with this? Or >>> are you taking the lack of *dissenting* messages as a sign of consensus? >>> >>> Dan >>> >>> P.S. I agree with this action, by the way, and did hum to adopt in the >room >>> in Minneapolis. >>> >>> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >>> >>>> In Minneapolis, there was a hum taken which indicated rough consensus >>>> to move towards adopting the P2PSIP diagnostics draft as a working >>>> group item. Since there were also a number of corrections/changes >>>> requested, the chairs asked the authors to iterate the draft and post >>>> it, and then we would verify the consensus on list. >>>> >>>> The authors posted the revisions to the draft a few weeks ago: >>>> >>>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>>> >>>> I'd like to ask for list consensus to verify the consensus from the >>>> meeting in favor of adopting this work as a WG item. >>>> >>>> David (as chair) >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> -- >>> Dan York, CISSP, Director of Emerging Communication Technology >>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>> >>> Build voice applications based on open standards. >>> Find out how at http://www.voxeo.com/free >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jan 5 19:14:57 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 355303A687E; Mon, 5 Jan 2009 19:14:57 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60093A687E for ; Mon, 5 Jan 2009 19:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrKaSHg3l8-z for ; Mon, 5 Jan 2009 19:14:54 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6C7893A63D2 for ; Mon, 5 Jan 2009 19:14:54 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD100I5K50CU7@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 11:14:36 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KD1003SJ50CAR@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 11:14:36 +0800 (CST) Received: from s64081 ([10.164.12.60]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KD100K8J50BHL@szxml06-in.huawei.com> for p2psip@ietf.org; Tue, 06 Jan 2009 11:14:36 +0800 (CST) Date: Tue, 06 Jan 2009 11:14:35 +0800 From: Song Haibin In-reply-to: To: 'Bruce Lowekamp' Message-id: <009301c96fac$e73a3760$3c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Aclur9sKQPQVX3W5SyKy9FUHb8JiTAA+2GOg Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adoptdraft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Hi Bruce, >I've been in favor of adoption, and I am not going to change my opinion now. Many thanks! >When the revision was posted, it >should have been announced on the list and the changes made to it >brought to the attention of the wg members for discussion. I announced the new revision in the p2psip mailing list on Dec 17th. >I have technical concerns with this draft that have been mentioned >before (OWD can't be measured the way this draft proposes, and I don't >believe the multiple-responses-for-an-echo-request technique should be >supported). There is an editor note in section 6.1 which indicates OWD measurement will need more discussion. Echo method has been limited to be used in some trusted overlay network where it works. >I don't understand why the "diagnostic server" material was added to >this revision. I think it should be removed. If something like this >is desired, it should be entirely separate. This section will be removed. BR Haibin >Bruce > > > > >On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan wrote: >> Looking for objections, since we had consensus in the room in Minneapolis. >> >> Thanks for clarifying! >> >> David (as chair) >> >> On Fri, Dec 26, 2008 at 3:49 PM, Dan York wrote: >>> David, >>> >>> Are you expecting us to send messages to the list agreeing with this? Or >>> are you taking the lack of *dissenting* messages as a sign of consensus? >>> >>> Dan >>> >>> P.S. I agree with this action, by the way, and did hum to adopt in the room >>> in Minneapolis. >>> >>> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >>> >>>> In Minneapolis, there was a hum taken which indicated rough consensus >>>> to move towards adopting the P2PSIP diagnostics draft as a working >>>> group item. Since there were also a number of corrections/changes >>>> requested, the chairs asked the authors to iterate the draft and post >>>> it, and then we would verify the consensus on list. >>>> >>>> The authors posted the revisions to the draft a few weeks ago: >>>> >>>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>>> >>>> I'd like to ask for list consensus to verify the consensus from the >>>> meeting in favor of adopting this work as a WG item. >>>> >>>> David (as chair) >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> -- >>> Dan York, CISSP, Director of Emerging Communication Technology >>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>> >>> Build voice applications based on open standards. >>> Find out how at http://www.voxeo.com/free >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jan 6 04:56:44 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24EF93A6847; Tue, 6 Jan 2009 04:56:44 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1EE73A67AB for ; Tue, 6 Jan 2009 04:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTgrfFXDFgOr for ; Tue, 6 Jan 2009 04:56:42 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 01BFD3A6783 for ; Tue, 6 Jan 2009 04:56:41 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so4239902wag.5 for ; Tue, 06 Jan 2009 04:56:27 -0800 (PST) Received: by 10.114.205.1 with SMTP id c1mr14491524wag.128.1231246587818; Tue, 06 Jan 2009 04:56:27 -0800 (PST) Received: by 10.114.169.17 with HTTP; Tue, 6 Jan 2009 04:56:27 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2009 07:56:27 -0500 From: "Bruce Lowekamp" To: "Song Haibin" In-Reply-To: <009301c96fac$e73a3760$3c0ca40a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <009301c96fac$e73a3760$3c0ca40a@china.huawei.com> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] List consensus call to adoptdraft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org On Mon, Jan 5, 2009 at 10:14 PM, Song Haibin wrote: > Hi Bruce, > >>I've been in favor of adoption, and I am not going to change my opinion > now. > > Many thanks! > >>When the revision was posted, it >>should have been announced on the list and the changes made to it >>brought to the attention of the wg members for discussion. > > I announced the new revision in the p2psip mailing list on Dec 17th. > You're right, my apologies. I somehow entirely missed that. In that case, I really wish everyone else (such as myself) on the list had read it and responded more quickly... >>I have technical concerns with this draft that have been mentioned >>before (OWD can't be measured the way this draft proposes, and I don't >>believe the multiple-responses-for-an-echo-request technique should be >>supported). > > There is an editor note in section 6.1 which indicates OWD measurement will > need more discussion. Echo method has been limited to be used in some > trusted overlay network where it works. > Measuring OWD of a multi-hop path around an overlay is entirely possible if all the peers are synchronized to NTP servers. It's just that it can't be used for a single hop, and it's hard to confirm all the peers are properly synchronized. However, that timestamp is useful regardless of whether it can be used for OWD. So I would leave the timestamp the way it is, but just add some discussion that careful consideration needs to be given to how it's used. While differentiating "trusted" and "untrusted" overlays is useful for discussion points, I don't know how to apply the terms to real networks. Real networks are going to have a lot of shades of gray. All you're going to wind up with is a flag in the config file saying whether the overlay allows that multiple response echo method or not. However, my biggest concern is the difficulty of implementing it. There's both a problem that it's two different ways of implementing the same concept (which makes the implementation hard) and that this is the only case we have for a request that gets multiple responses each of which has meaning (much more complex than a normal request/response). Considering all of this, think there just needs to be a standard one-response-at-a-time method. Bruce >>I don't understand why the "diagnostic server" material was added to >>this revision. I think it should be removed. If something like this >>is desired, it should be entirely separate. > > This section will be removed. > > BR > Haibin > >>Bruce >> >> >> >> >>On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan > wrote: >>> Looking for objections, since we had consensus in the room in > Minneapolis. >>> >>> Thanks for clarifying! >>> >>> David (as chair) >>> >>> On Fri, Dec 26, 2008 at 3:49 PM, Dan York wrote: >>>> David, >>>> >>>> Are you expecting us to send messages to the list agreeing with this? > Or >>>> are you taking the lack of *dissenting* messages as a sign of consensus? >>>> >>>> Dan >>>> >>>> P.S. I agree with this action, by the way, and did hum to adopt in the > room >>>> in Minneapolis. >>>> >>>> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >>>> >>>>> In Minneapolis, there was a hum taken which indicated rough consensus >>>>> to move towards adopting the P2PSIP diagnostics draft as a working >>>>> group item. Since there were also a number of corrections/changes >>>>> requested, the chairs asked the authors to iterate the draft and post >>>>> it, and then we would verify the consensus on list. >>>>> >>>>> The authors posted the revisions to the draft a few weeks ago: >>>>> >>>>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>>>> >>>>> I'd like to ask for list consensus to verify the consensus from the >>>>> meeting in favor of adopting this work as a WG item. >>>>> >>>>> David (as chair) >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> -- >>>> Dan York, CISSP, Director of Emerging Communication Technology >>>> Office of the CTO Voxeo Corporation dyork@voxeo.com >>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>>> >>>> Build voice applications based on open standards. >>>> Find out how at http://www.voxeo.com/free >>>> >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>_______________________________________________ >>P2PSIP mailing list >>P2PSIP@ietf.org >>https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jan 6 07:13:41 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744323A67F6; Tue, 6 Jan 2009 07:13:41 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32323A6853; Mon, 5 Jan 2009 08:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjEXVrCD0kyD; Mon, 5 Jan 2009 08:04:28 -0800 (PST) Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 7BF9A3A67A5; Mon, 5 Jan 2009 08:04:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id 5B46821AF59; Mon, 5 Jan 2009 18:04:15 +0200 (EET) Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27826-04; Mon, 5 Jan 2009 18:04:11 +0200 (EET) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id 619B721AF55; Mon, 5 Jan 2009 18:04:11 +0200 (EET) Received: from [193.167.187.26] (halko.pc.infrahip.net [193.167.187.26]) by argo.otaverkko.fi (Postfix) with ESMTP id 5524125ED06; Mon, 5 Jan 2009 18:04:11 +0200 (EET) Message-ID: <49622F7B.2000909@hiit.fi> Date: Mon, 05 Jan 2009 18:04:11 +0200 From: Miika Komu User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: hipsec@ietf.org, hipsec-rg@listserv.cybertrust.com X-Virus-Scanned: amavisd-new at otaverkko.fi X-Mailman-Approved-At: Tue, 06 Jan 2009 07:13:39 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] [Fwd: hipl release 1.0.4] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: miika.komu@hiit.fi List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org FYI, -------- Original Message -------- Subject: hipl release 1.0.4 Date: Mon, 05 Jan 2009 18:02:49 +0200 From: Miika Komu Reply-To: miika.komu@hiit.fi To: hipl-users@freelists.org, hipl-announce@freelists.org Hi folks, we have published HIP for Linux (HIPL) release 1.0.4 in the URL below: http://infrahip.hiit.fi/hipl/release/1.0.4/ The release includes binaries for Ubuntu, Fedora, CentOS and Maemo for Nokia Tablets. The binaries (and updates) can also be downloaded using apt and yum in few steps using the instructions below: http://infrahip.hiit.fi/index.php?index=download The release includes many improvements including a number of bug fixes and better support for infrastructure (DNS, Bamboo DHT, rendezvous). Please refer to release notes for further details. The main theme in the following release (1.0.5) is on fault-tolerant mobility management. Suggestions for improvements and bugs can be reported at: http://www.freelists.org/list/hipl-users _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 9 06:07:17 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD443A6949; Fri, 9 Jan 2009 06:07:17 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6863A68AB for ; Fri, 9 Jan 2009 06:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9pt0Gac2YwM for ; Fri, 9 Jan 2009 06:07:16 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 5B0B63A67CF for ; Fri, 9 Jan 2009 06:07:16 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so8686098rvf.49 for ; Fri, 09 Jan 2009 06:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=j9BFXkqQiPkqbRTAO1Mx7aQyKpzMF8UVgpFwDLUUrcQ=; b=nyQRkA2YdSk4Mi4RuUcu3wPz9DDJvxAMn+xJT0Y1sJd+6x7+qM4Ggn8Yy+KQYrEvWB Z8ifGraNN+mSlz71txDyRi5/VJaiFMMSWSgChBFbxcge0LjQzyiZafuBD8F1g0qKF2ZI 6ktdrW+NXyhUMUVTecmWe4AcqmLWrDbUO5yl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=JagiV6WVP/3gU/wPbflHMqGY9HGKzT8Emr8YghsLD3EH1bR/BZHjrKz9Df6e5PTfxc X1xQBxWc+N9QwZYn5DRaRFwch1p1tRqpFhj7awB0yfkkSVMmadeynZwfqzTnYo8bdIHR psp4o3sMRv5ftv7T9YT0zjemsO03MAAgDuGCY= Received: by 10.142.144.16 with SMTP id r16mr10738870wfd.77.1231510021810; Fri, 09 Jan 2009 06:07:01 -0800 (PST) Received: by 10.143.75.6 with HTTP; Fri, 9 Jan 2009 06:07:01 -0800 (PST) Message-ID: <8b2769930901090607u5b6caf7ci57fdcf930c89701f@mail.gmail.com> Date: Fri, 9 Jan 2009 09:07:01 -0500 From: "David A. Bryan" To: p2psip@ietf.org In-Reply-To: <8b2769930812260708w5d97d5aelefefcb0bb2826316@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <8b2769930812260708w5d97d5aelefefcb0bb2826316@mail.gmail.com> X-Google-Sender-Auth: e625ce1020f63d93 Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Since we've given this two weeks, and haven't seen any objections to the adoption of draft-zheng-p2psip-diagnose-04 as a WG item, the diagnostic draft is now a WG item. There were obviously many technical comments and concerns, so I expect this item will be a very active one in the WG going forward. Please keep the comments and discussion going -- I'm sure the authors will appreciate the feedback. David (as chair) On Fri, Dec 26, 2008 at 10:08 AM, David A. Bryan wrote: > In Minneapolis, there was a hum taken which indicated rough consensus > to move towards adopting the P2PSIP diagnostics draft as a working > group item. Since there were also a number of corrections/changes > requested, the chairs asked the authors to iterate the draft and post > it, and then we would verify the consensus on list. > > The authors posted the revisions to the draft a few weeks ago: > > http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt > > I'd like to ask for list consensus to verify the consensus from the > meeting in favor of adopting this work as a WG item. > > David (as chair) > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 9 10:02:11 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA8528C1C2; Fri, 9 Jan 2009 10:02:11 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFB428C1BD for ; Fri, 9 Jan 2009 10:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy8DwDfy4jQv for ; Fri, 9 Jan 2009 10:02:08 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 5072528C1AF for ; Fri, 9 Jan 2009 10:02:08 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so5294451wag.5 for ; Fri, 09 Jan 2009 10:01:54 -0800 (PST) Received: by 10.114.124.1 with SMTP id w1mr17045043wac.13.1231524113978; Fri, 09 Jan 2009 10:01:53 -0800 (PST) Received: by 10.114.169.17 with HTTP; Fri, 9 Jan 2009 10:01:53 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2009 13:01:53 -0500 From: "Bruce Lowekamp" To: "p2psip@ietf.org" MIME-Version: 1.0 Content-Disposition: inline Subject: [P2PSIP] reload-base-01a posted to p2psip.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org We've updated the base reload draft. The current version is posted at http://www.p2psip.org/drafts/draft-ietf-p2psip-base-01a.html http://www.p2psip.org/drafts/draft-ietf-p2psip-base-01a.txt Note that the location and the -01a notation are due to the ongoing issues with the updates to BCP78. -01 was submitted earlier, although we subsequently realized that updates to the base draft could not be made under the new BCP78 terms. Until that issue is resolved, we will post updates to the p2psip.org site and maintain a -01x naming scheme. Changes since -00: * removed TUNNEL method * allow implementations more flexibility in picking finger table entry and revise random range * decouple overlay configuration from enrollment server * add error for data too large * change architecture to overlay perspective from previous revision and update terminology in document to match * reordered message routing section to clarify that other routing algorithms are possible besides symmetric recursive. * clarified document ipr terms _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 9 10:23:23 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF593A68BA; Fri, 9 Jan 2009 10:23:23 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9723A688D for ; Fri, 9 Jan 2009 10:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RSl1ogjUS5h for ; Fri, 9 Jan 2009 10:23:21 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id AF4463A67FC for ; Fri, 9 Jan 2009 10:23:21 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id A272850822; Fri, 9 Jan 2009 10:39:32 -0800 (PST) Date: Fri, 09 Jan 2009 10:39:31 -0800 From: Eric Rescorla To: "Narayanan, Vidya" In-Reply-To: References: <20081219164421.9858050822@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20090109183932.A272850822@romeo.rtfm.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Dynamically introducing new types X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org At Wed, 24 Dec 2008 13:05:26 -0800, Narayanan, Vidya wrote: > > What you are suggesting is to still do kind-specific data > authorization and access control, but allow dynamic addition of new > kinds. Yes. > I think this works, but, it is simpler to just do this at > the overlay level - this means indicating the type of authorization > used in the protocol (say, we define the 5 or so rules you have > below and allow that to be signaled in the protocol). I don't understand what "signalled in the protocol" means. This is being signalled in the protocol in the sense that the protocol has a mechanism for moving the configuration document around. Having it > tied to the kind allows additional verification that the particular > authorization model is indeed the right one to use for that kind - > unless we need that property, I don't see a reason to tie it to the > kind itself. I'm sorry, I'm not gettign your point here: we already have kinds which we expect to run on the same overlay which require having different access control rules. So, yes, I think that each kind needs to have its own set of rules in a working overlay. > So, I prefer that we signal the authorization rule in the protocol > rather than have this complexity of having kind level knowledge in > order to perform the authorization. > > All that said, I agree with the 5 rules you wrote below. I'd > recommend adding the following: > > - User must have a certificate with H(NodeID || "usage specific string") == Resource-ID and > - User must have a certificate with H(user_id || "usage specific string") == Resource-ID > > This allows the flexibility to usages to qualify the data they are storing as they see fit. I don't really understand how this works. Usages aren't a first class concept in RELOAD. They're just a document organizational concept. The only relevant protocol concept is "kind". If I do s/usage/kind/, is that what you are suggesting? If so, where does the string come from. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 9 23:32:39 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20433A69F8; Fri, 9 Jan 2009 23:32:39 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6383A69F3 for ; Fri, 9 Jan 2009 23:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.462 X-Spam-Level: X-Spam-Status: No, score=-105.462 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF0D8CPpWCSM for ; Fri, 9 Jan 2009 23:32:37 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9DB323A69F7 for ; Fri, 9 Jan 2009 23:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1231572744; x=1263108744; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Eric=20Rescorla=20|CC:=20"p2 psip@ietf.org"=20|Date:=20Fri,=209=20Jan =202009=2023:31:48=20-0800|Subject:=20RE:=20[P2PSIP]=20Dy namically=20introducing=20new=20types|Thread-Topic:=20[P2 PSIP]=20Dynamically=20introducing=20new=20types |Thread-Index:=20Aclyh2AaDUQDoxZPTuGPQYEdNwxifQAGbQwg |Message-ID:=20|References:=20<2008121916442 1.9858050822@romeo.rtfm.com>=0D=0A=09=0D=0A =20<20090109183932.A272850822@romeo.rtfm.com> |In-Reply-To:=20<20090109183932.A272850822@romeo.rtfm.com >|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5490"=3B=20a=3D"14544302"; bh=Wr4Lb4O8LSB13D5bKc7W7jCvc9m909O7lkz3GxnbINg=; b=Qql3vQmP+KCXjP5ole1ueRTHUS/mRNBdUPJqYWIK1zVKW9LB/0WhWhts ht1oGZg3ibkePlRd8Mj0Wxaj4S8xXc4N7G75EmRDqO9kbpxmm+4pIqOXJ RKBUtrjlR9ZMDp+VfR+XFLj7BlTSmzdjk8nI1tiW+3Kmw/W0RAWO3Krg7 I=; X-IronPort-AV: E=McAfee;i="5300,2777,5490"; a="14544302" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jan 2009 23:32:04 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0A7W42M023654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Jan 2009 23:32:04 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0A7Vsi2009541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Jan 2009 23:32:03 -0800 (PST) Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 9 Jan 2009 23:31:54 -0800 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 9 Jan 2009 23:31:53 -0800 From: "Narayanan, Vidya" To: Eric Rescorla Date: Fri, 9 Jan 2009 23:31:48 -0800 Thread-Topic: [P2PSIP] Dynamically introducing new types Thread-Index: Aclyh2AaDUQDoxZPTuGPQYEdNwxifQAGbQwg Message-ID: References: <20081219164421.9858050822@romeo.rtfm.com> <20090109183932.A272850822@romeo.rtfm.com> In-Reply-To: <20090109183932.A272850822@romeo.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Dynamically introducing new types X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Friday, January 09, 2009 10:40 AM > To: Narayanan, Vidya > Cc: Eric Rescorla; p2psip@ietf.org > Subject: Re: [P2PSIP] Dynamically introducing new types > > At Wed, 24 Dec 2008 13:05:26 -0800, > Narayanan, Vidya wrote: > > > > What you are suggesting is to still do kind-specific data > > authorization and access control, but allow dynamic addition of new > > kinds. > > Yes. > > > > I think this works, but, it is simpler to just do this at > > the overlay level - this means indicating the type of authorization > > used in the protocol (say, we define the 5 or so rules you have > > below and allow that to be signaled in the protocol). > > I don't understand what "signalled in the protocol" means. > This is being signalled in the protocol in the sense that > the protocol has a mechanism for moving the configuration document > around. > What I meant was that the type of authorization rule applied will be indicated in the message, rather than needing to look up a configuration document. > > Having it > > tied to the kind allows additional verification that the particular > > authorization model is indeed the right one to use for that kind - > > unless we need that property, I don't see a reason to tie it to the > > kind itself. > > I'm sorry, I'm not gettign your point here: we already have > kinds which we expect to run on the same overlay which require > having different access control rules. So, yes, I think that > each kind needs to have its own set of rules in a working overlay. > I agree that the authorization rules itself are kind specific. However, I'm saying that the node verifying authorization only needs to know which rule to apply - there is no need to verify that the rule applied is the correct one for the particular kind. If we said that, there is no need to retrieve the configuration document and looking up the authorization rule corresponding to a kind. The verifying node can apply the authorization rule indicated in the message and that will be sufficient. > > > So, I prefer that we signal the authorization rule in the protocol > > rather than have this complexity of having kind level knowledge in > > order to perform the authorization. > > > > All that said, I agree with the 5 rules you wrote below. I'd > > recommend adding the following: > > > > - User must have a certificate with H(NodeID || "usage specific > string") == Resource-ID and > > - User must have a certificate with H(user_id || "usage specific > string") == Resource-ID > > > > This allows the flexibility to usages to qualify the data they are > storing as they see fit. > > I don't really understand how this works. Usages aren't a first class > concept in RELOAD. > They're just a document organizational concept. The only relevant > protocol concept > is "kind". If I do s/usage/kind/, is that what you are suggesting? If > so, > where does the string come from. > I'm talking about providing application specific resource name construction flexibility. A particular usage may decide to allow its data to be further spread in the overlay. For instance, sip.voip:alice@exampledht.org and sip.im:alice@exampledht.org may be two different objects stored on the overlay by the SIP usage. Here, "sip.voip" and "sip.im" are specified by the usage. This would be carried in the message to ensure authorization verification by the target node. The construction of the string itself is only of significance to the usage. Vidya > -Ekr > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jan 11 23:08:29 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2DC3A67F0; Sun, 11 Jan 2009 23:08:29 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430623A67F0 for ; Sun, 11 Jan 2009 23:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V5pL7T+X6Xm for ; Sun, 11 Jan 2009 23:08:27 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 8E5503A67D0 for ; Sun, 11 Jan 2009 23:08:26 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 13so2209171fge.41 for ; Sun, 11 Jan 2009 23:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :mime-version:content-type:x-mailer:thread-index:content-language :message-id; bh=L1TOPvPJ9HHhrf6McUrIxHldeIvrvDPm9dmJbuqp0QY=; b=qIRbJ5wCGpK1sw5P1KA8elpk/QaDmraGRua8BKyXsOBcVZCe3unFSCQ4c+Yrqy+e95 1pGx/aIR6MvFkJvSdJTo9ujVqlhXbhSktUhM39N0B7n9HX8TQmWxpbmBPu4i3oi4+eMP QHplMdbS2/HZdk+npXMNOA7rQ3fGFt9GypQc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:date:mime-version:content-type:x-mailer :thread-index:content-language:message-id; b=D2ys6FfdA3CzXSDLnq4+E08fsqOkTVAu5m5c7bF+x+F/vH8AzTeSv2m8XfVJHp9y8k qig96N6mSEoqrB9yYAUlzQfh9yCXtU8X/fMX9ypeFtz1BqyWrOX/RizPtIE6W7hoQD91 mmmIBZEVo9uzN1IslFdxeiKRqu4qokP7q0WQ8= Received: by 10.86.51.10 with SMTP id y10mr16516553fgy.51.1231744090568; Sun, 11 Jan 2009 23:08:10 -0800 (PST) Received: from windows8d787f9 (bzq-79-179-57-39.red.bezeqint.net [79.179.57.39]) by mx.google.com with ESMTPS id l19sm11095828fgb.29.2009.01.11.23.08.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Jan 2009 23:08:09 -0800 (PST) From: "Roni Even" To: Date: Mon, 12 Jan 2009 09:06:54 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl0hFnTzTUEp3bOQ4iPknifKcll0A== Content-Language: en-us Message-ID: <496aec59.1358560a.5b5a.5d2b@mx.google.com> Subject: [P2PSIP] new draft-jiang-p2psip-relay-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103133609==" Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org This is a multipart message in MIME format. --===============2103133609== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C97495.25D56160" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0009_01C97495.25D56160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, In Minneapolis we presented draft-jiang-p2psip-relay-00. There was a hum that showed consensus to add support for direct route mode. On the issue of using relay peer and discovering of NAT behavior the decision was to continue the discussion on the list. One of the questions in the meeting was about using TURN for getting a relay peer service. This topic was discussed in a separate thread pointing out that the sending peer does not know that the address of the target and cannot tell it to the TURN server, so that TURN server will discard the message from the target of the message. The other point was that using relay peer is an optional mode and is not dependent on discovery of NAT behavior, for example the relay peers can be provisioned by the service provider or be part of the bootstrap peers. We updated the draft and submitted draft-jiang-p2psip-relay-01. In the updated draft we tried to separate the NAT behavior discovery, offering options to find relay peers from the issue of how to use a relay peer. The draft explains that the sender of the request decides if to offer direct response or a relay peer as the recommended response method based on trying to find if it has a publicly reachable address or looking for relay peer service. It can have better success based on past experience. The sender of the request can try, for example, using a relay peer and if fails to get a response he can switch to symmetric routing when retrying the request. We hope that the new draft addresses the questions and people are more comfortable with these optional modes. Please review the new draft. You can get the draft by accessing the link http://tools.ietf.org/id/draft-jiang-p2psip-relay-01.txt Thanks Roni Even ------=_NextPart_000_0009_01C97495.25D56160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In Minneapolis we presented = draft-jiang-p2psip-relay-00. There was a hum that showed consensus to add support for direct route = mode. On the issue of using relay peer and discovering of NAT behavior the = decision was to continue the discussion on the list.

 

One of the questions in the meeting was about using = TURN for getting a relay peer service. This topic was discussed in a separate = thread pointing out that the sending peer does not know that the address of the = target and cannot tell it to the TURN server, so that TURN server will discard = the message from the target of the message. The other point was that using = relay peer is an optional mode and is not dependent on discovery of NAT = behavior, for example the relay peers can be provisioned by the service provider or be = part of the bootstrap peers.

 

We updated the draft and submitted draft-jiang-p2psip-relay-01. In the updated draft we tried to separate = the NAT behavior discovery, offering options to find relay peers from the issue = of how to use a relay peer.

The draft explains that the sender of the request = decides if to offer direct response or a relay peer as the recommended response = method based on trying to find if it has a publicly reachable address or = looking for relay peer service. It can have better success based on past = experience.  The sender of the request can try, for example, using a relay peer and = if fails to get a response he can switch to symmetric routing when retrying the = request.

 

We hope that the new draft addresses the questions = and people are more comfortable with these optional modes.

 

Please review the new draft. You can get the draft = by accessing the link http://= tools.ietf.org/id/draft-jiang-p2psip-relay-01.txt

 

Thanks

Roni Even

------=_NextPart_000_0009_01C97495.25D56160-- --===============2103133609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --===============2103133609==-- From p2psip-bounces@ietf.org Mon Jan 12 04:48:07 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1833A686D; Mon, 12 Jan 2009 04:48:07 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4A23A686D for ; Mon, 12 Jan 2009 04:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vGRD13cTcY7 for ; Mon, 12 Jan 2009 04:48:05 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 3DE353A67A8 for ; Mon, 12 Jan 2009 04:48:05 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so5974777wag.5 for ; Mon, 12 Jan 2009 04:47:49 -0800 (PST) Received: by 10.114.146.6 with SMTP id t6mr19040042wad.207.1231764469712; Mon, 12 Jan 2009 04:47:49 -0800 (PST) Received: by 10.115.17.5 with HTTP; Mon, 12 Jan 2009 04:47:49 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2009 07:47:49 -0500 From: "Bruce Lowekamp" To: "Narayanan, Vidya" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20081219164421.9858050822@romeo.rtfm.com> <20090109183932.A272850822@romeo.rtfm.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Dynamically introducing new types X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Vidya, I think you're right that a system could work that way, but it seems too expensive to me. Assuming that many/most overlays would only want to store kinds that are authorized for the overlay, each kind requires a description (which is rather small) and a signature (which is not). The signatures in the messages already make them large enough that we need to deal properly with fragmentation. Adding an additional set (or more) per message when we can just propagate the information once in the overlay config file and be done with it seems like a waste. Bruce On Sat, Jan 10, 2009 at 2:31 AM, Narayanan, Vidya wrote: > > >> -----Original Message----- >> From: Eric Rescorla [mailto:ekr@networkresonance.com] >> Sent: Friday, January 09, 2009 10:40 AM >> To: Narayanan, Vidya >> Cc: Eric Rescorla; p2psip@ietf.org >> Subject: Re: [P2PSIP] Dynamically introducing new types >> >> At Wed, 24 Dec 2008 13:05:26 -0800, >> Narayanan, Vidya wrote: >> > >> > What you are suggesting is to still do kind-specific data >> > authorization and access control, but allow dynamic addition of new >> > kinds. >> >> Yes. >> >> >> > I think this works, but, it is simpler to just do this at >> > the overlay level - this means indicating the type of authorization >> > used in the protocol (say, we define the 5 or so rules you have >> > below and allow that to be signaled in the protocol). >> >> I don't understand what "signalled in the protocol" means. >> This is being signalled in the protocol in the sense that >> the protocol has a mechanism for moving the configuration document >> around. >> > > What I meant was that the type of authorization rule applied will be indicated in the message, rather than needing to look up a configuration document. > >> >> Having it >> > tied to the kind allows additional verification that the particular >> > authorization model is indeed the right one to use for that kind - >> > unless we need that property, I don't see a reason to tie it to the >> > kind itself. >> >> I'm sorry, I'm not gettign your point here: we already have >> kinds which we expect to run on the same overlay which require >> having different access control rules. So, yes, I think that >> each kind needs to have its own set of rules in a working overlay. >> > > I agree that the authorization rules itself are kind specific. However, I'm saying that the node verifying authorization only needs to know which rule to apply - there is no need to verify that the rule applied is the correct one for the particular kind. If we said that, there is no need to retrieve the configuration document and looking up the authorization rule corresponding to a kind. The verifying node can apply the authorization rule indicated in the message and that will be sufficient. > >> >> > So, I prefer that we signal the authorization rule in the protocol >> > rather than have this complexity of having kind level knowledge in >> > order to perform the authorization. >> > >> > All that said, I agree with the 5 rules you wrote below. I'd >> > recommend adding the following: >> > >> > - User must have a certificate with H(NodeID || "usage specific >> string") == Resource-ID and >> > - User must have a certificate with H(user_id || "usage specific >> string") == Resource-ID >> > >> > This allows the flexibility to usages to qualify the data they are >> storing as they see fit. >> >> I don't really understand how this works. Usages aren't a first class >> concept in RELOAD. >> They're just a document organizational concept. The only relevant >> protocol concept >> is "kind". If I do s/usage/kind/, is that what you are suggesting? If >> so, >> where does the string come from. >> > > I'm talking about providing application specific resource name construction flexibility. A particular usage may decide to allow its data to be further spread in the overlay. For instance, sip.voip:alice@exampledht.org and sip.im:alice@exampledht.org may be two different objects stored on the overlay by the SIP usage. Here, "sip.voip" and "sip.im" are specified by the usage. This would be carried in the message to ensure authorization verification by the target node. The construction of the string itself is only of significance to the usage. > > Vidya > >> -Ekr >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jan 12 12:56:13 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC59A3A67F3; Mon, 12 Jan 2009 12:56:12 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A6E3A68D0 for ; Mon, 12 Jan 2009 12:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id youU72YiSkC7 for ; Mon, 12 Jan 2009 12:56:10 -0800 (PST) Received: from kilo.local (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 726573A6405 for ; Mon, 12 Jan 2009 12:56:10 -0800 (PST) Received: from kilo.local (localhost [127.0.0.1]) by kilo.local (Postfix) with ESMTP id 3B911EA71B; Mon, 12 Jan 2009 12:55:56 -0800 (PST) Date: Mon, 12 Jan 2009 12:55:56 -0800 From: Eric Rescorla To: "Narayanan, Vidya" In-Reply-To: References: <20081219164421.9858050822@romeo.rtfm.com> <20090109183932.A272850822@romeo.rtfm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20090112205556.3B911EA71B@kilo.local> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Dynamically introducing new types X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org At Fri, 9 Jan 2009 23:31:48 -0800, Narayanan, Vidya wrote: > > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Sent: Friday, January 09, 2009 10:40 AM > > To: Narayanan, Vidya > > Cc: Eric Rescorla; p2psip@ietf.org > > Subject: Re: [P2PSIP] Dynamically introducing new types > > > > At Wed, 24 Dec 2008 13:05:26 -0800, > > Narayanan, Vidya wrote: > > > > > > What you are suggesting is to still do kind-specific data > > > authorization and access control, but allow dynamic addition of new > > > kinds. > > > > Yes. > > > > > > > I think this works, but, it is simpler to just do this at > > > the overlay level - this means indicating the type of authorization > > > used in the protocol (say, we define the 5 or so rules you have > > > below and allow that to be signaled in the protocol). > > > > I don't understand what "signalled in the protocol" means. > > This is being signalled in the protocol in the sense that > > the protocol has a mechanism for moving the configuration document > > around. > > > > What I meant was that the type of authorization rule applied will be > indicated in the message, rather than needing to look up a > configuration document. I'm sorry, I still don't see how this is going to work: the sender and the receiver of the message are potentially adversarial: for instance, the sender may want to delete data belonging to someone else. This means that the recipient needs to be able to determine the correct access control rule in a way that the sender can't interfere with. Otherwise the sender can just choose an access control rule which is most permissive for his purposes. > I'm talking about providing application specific resource name > construction flexibility. A particular usage may decide to allow > its data to be further spread in the overlay. For instance, > sip.voip:alice@exampledht.org and sip.im:alice@exampledht.org may be > two different objects stored on the overlay by the SIP usage. Here, > "sip.voip" and "sip.im" are specified by the usage. This would be > carried in the message to ensure authorization verification by the > target node. The construction of the string itself is only of > significance to the usage. Again, usages aren't a first class construct, so there's no way for a usage to specify anything like this. That's what kinds are for. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jan 14 00:22:19 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3D63A6819; Wed, 14 Jan 2009 00:22:19 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD74E28C153 for ; Wed, 14 Jan 2009 00:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.655 X-Spam-Level: **** X-Spam-Status: No, score=4.655 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_50=0.001, DEAR_SOMETHING=1.605, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXvGqSuz0XfC for ; Wed, 14 Jan 2009 00:22:17 -0800 (PST) Received: from maillog.itri.org.tw (maillog.itri.org.tw [61.61.254.20]) by core3.amsl.com (Postfix) with ESMTP id DE5883A6819 for ; Wed, 14 Jan 2009 00:22:16 -0800 (PST) Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.12.10/8.12.10) with ESMTP id n0E8YFMs020794 for ; Wed, 14 Jan 2009 16:34:15 +0800 (CST) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id n0E8Mh5T021131 for ; Wed, 14 Jan 2009 16:22:43 +0800 (CST) Received: from ms33.itri.org.tw (ms33.itri.org.tw [140.96.151.30]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id n0E8MgC1021123 for ; Wed, 14 Jan 2009 16:22:43 +0800 (CST) Received: from 52092035393 ([140.96.151.160]) by ms33.itri.org.tw (Lotus Domino Release 7.0.3FP1) with ESMTP id 2009011416215890-7625 ; Wed, 14 Jan 2009 16:21:58 +0800 From: "JeffreyHo" To: Date: Wed, 14 Jan 2009 16:22:32 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acl2IT8sPAgrREQkR/iVXvFIJbnpGg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-MIMETrack: Itemize by SMTP Server on MS33/ITRI(Release 7.0.3FP1|February 24, 2008) at 2009-01-14 16:21:59, Serialize by Router on MS33/ITRI(Release 7.0.3FP1|February 24, 2008) at 2009-01-14 16:22:00, Serialize complete at 2009-01-14 16:22:00 Subject: [P2PSIP] Would the overlay name of P2P RELOAD network be unique? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0379131532==" Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0379131532== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C97664.506037E0" This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C97664.506037E0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Dear sir, In RELOAD overlay network, would the overlay name for each isolated P2P overlay be unique? If two P2PSIP service providers want to build up their own P2P RELOAD overlay and have own dedicated enrollment server but unfortunately they configure the same overlay name, will this situation result in any abnormal or conflict operations within these two P2P overlay networks? If yes, how we ensure the uniqueness of overlay name? Would the mechanism for applying an unique overlay name like applying domain name be necessary? Thanks a lot. BR, Jeffrey %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. ------=_NextPart_000_0027_01C97664.506037E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5" [P2PSIP] Would the overlay name of P2P RELOAD network be= unique?

Dear sir,

In RELOAD overlay network,= would the overlay name for each isolated P2P overlay be unique? If two= P2PSIP service providers want to build up their own P2P RELOAD overlay and= have own dedicated enrollment server but unfortunately they configure the= same overlay name, will this situation result in any abnormal or conflict= operations within these two P2P overlay networks? If yes, how we ensure= the uniqueness of overlay name? Would the mechanism for applying an unique= overlay name like applying domain name be necessary?

Thanks a lot.

BR,
Jeffrey      

=A5=BB=ABH=A5=F3=A5i= =AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A=ABD=AB=FC=A9w=A4=A7=A6= =AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4=A6=C5S=A5=BB=ABH=A5=F3= =A4=BA=AEe=A1A=A8=C3=BD=D0=BEP=B7=B4=A6=B9=ABH=A5=F3=A1C
This email may contain confidential information. Please do not use or= disclose it in any way and delete it if you are not the intended= recipient.
------=_NextPart_000_0027_01C97664.506037E0-- --===============0379131532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --===============0379131532==-- From p2psip-bounces@ietf.org Thu Jan 15 00:50:40 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96EED3A6A39; Thu, 15 Jan 2009 00:50:40 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9293A6A39 for ; Thu, 15 Jan 2009 00:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.181 X-Spam-Level: X-Spam-Status: No, score=-0.181 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_HELO_EQ_DSL_3=1.022] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-HYOrIScraQ for ; Thu, 15 Jan 2009 00:50:38 -0800 (PST) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id E83933A68B1 for ; Thu, 15 Jan 2009 00:50:37 -0800 (PST) Received: from kiwi.cc.columbia.edu (kiwi.cc.columbia.edu [128.59.28.104]) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id n0F8oKDR023817; Thu, 15 Jan 2009 03:50:20 -0500 (EST) Received: from kiwi.cc.columbia.edu (localhost [127.0.0.1]) by kiwi.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n0F8oKr3026913; Thu, 15 Jan 2009 03:50:20 -0500 (EST) Received: (from www@localhost) by kiwi.cc.columbia.edu (8.14.3/8.14.1/Submit) id n0F8oJYf026912; Thu, 15 Jan 2009 03:50:19 -0500 (EST) Received: from dsl-241-141-233.telkomadsl.co.za (dsl-241-141-233.telkomadsl.co.za [41.241.141.233]) by cubmail.cc.columbia.edu (Horde MIME library) with HTTP; Thu, 15 Jan 2009 03:50:19 -0500 Message-ID: <20090115035019.lsh592ysf4gcwccs@cubmail.cc.columbia.edu> Date: Thu, 15 Jan 2009 03:50:19 -0500 From: sa2086@columbia.edu To: Roni Even References: <496aec59.1358560a.5b5a.5d2b@mx.google.com> In-Reply-To: <496aec59.1358560a.5b5a.5d2b@mx.google.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-CubMail-Sender: sa2086@columbia.edu X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] new draft-jiang-p2psip-relay-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes" Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org There are at least two issues to make direct response work in RPR which can be more explicitly addressed in the draft: a) TURN server permissions b) TURN server transport address a) TURN server creates a permission on the basis of IP/port tuples. When sender requests a direct response for a request sent in a recursive manner, the IP/port tuples become irrelevant. Rather, the message identifier in the RELOAD message has to be used for matching responses to requests. This will need a new TURN profile. b) The request originator must specify the IP address and port on which the response will be received. For DPR, the draft should clearly state that the response must not be encapsulated within a STUN/TURN message. The draft should also specify that if ROUTE-QUERY is used, there is no need for direct or relay response routing. -salman Quoting Roni Even : > Hi, > > > > In Minneapolis we presented draft-jiang-p2psip-relay-00. There was a hum > that showed consensus to add support for direct route mode. On the issue of > using relay peer and discovering of NAT behavior the decision was to > continue the discussion on the list. > > > > One of the questions in the meeting was about using TURN for getting a relay > peer service. This topic was discussed in a separate thread pointing out > that the sending peer does not know that the address of the target and > cannot tell it to the TURN server, so that TURN server will discard the > message from the target of the message. The other point was that using relay > peer is an optional mode and is not dependent on discovery of NAT behavior, > for example the relay peers can be provisioned by the service provider or be > part of the bootstrap peers. > > > > We updated the draft and submitted draft-jiang-p2psip-relay-01. In the > updated draft we tried to separate the NAT behavior discovery, offering > options to find relay peers from the issue of how to use a relay peer. > > The draft explains that the sender of the request decides if to offer direct > response or a relay peer as the recommended response method based on trying > to find if it has a publicly reachable address or looking for relay peer > service. It can have better success based on past experience. The sender of > the request can try, for example, using a relay peer and if fails to get a > response he can switch to symmetric routing when retrying the request. > > > > We hope that the new draft addresses the questions and people are more > comfortable with these optional modes. > > > > Please review the new draft. You can get the draft by accessing the link > http://tools.ietf.org/id/draft-jiang-p2psip-relay-01.txt > > > > Thanks > > Roni Even > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jan 15 01:21:07 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7313A688D; Thu, 15 Jan 2009 01:21:07 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61EAA3A67E6 for ; Thu, 15 Jan 2009 01:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdMVWRRTCHAd for ; Thu, 15 Jan 2009 01:21:04 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D0CEE3A67A1 for ; Thu, 15 Jan 2009 01:21:03 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDI00JKE9WI36@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 15 Jan 2009 17:19:30 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDI009VZ9WIU2@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 15 Jan 2009 17:19:30 +0800 (CST) Received: from j36340a ([10.164.12.23]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDI002DC9WISU@szxml06-in.huawei.com> for p2psip@ietf.org; Thu, 15 Jan 2009 17:19:30 +0800 (CST) Date: Thu, 15 Jan 2009 17:19:28 +0800 From: jiangxingfeng In-reply-to: <20090115035019.lsh592ysf4gcwccs@cubmail.cc.columbia.edu> To: sa2086@columbia.edu, 'Roni Even' Message-id: <00ae01c976f2$5deb1360$170ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl27lgmcY3sq/cCSFGHnbvJ/kpwXwAAjSaw Cc: p2psip@ietf.org Subject: Re: [P2PSIP] new draft-jiang-p2psip-relay-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Hi, Salman: Thanks for your comments. Response in line. Regards Jiang XingFeng > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > sa2086@columbia.edu > Sent: Thursday, January 15, 2009 4:50 PM > To: Roni Even > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] new draft-jiang-p2psip-relay-01 > > There are at least two issues to make direct response work in RPR > which can be more explicitly addressed in the draft: > > a) TURN server permissions > b) TURN server transport address > > a) TURN server creates a permission on the basis of IP/port tuples. > When sender requests a direct response for a request sent in a > recursive manner, the IP/port tuples become irrelevant. Rather, the > message identifier in the RELOAD message has to be used for matching > responses to requests. This will need a new TURN profile. > > b) The request originator must specify the IP address and port on > which the response will be received. RPR does not try to use the TURN server to relay the response. Rather it tries to use a relay peer to forward the response from the destination peer to the source peer. The relay peer should be tested as publicly reachable. A typical message flow for a RPR is as follows: 1. Peer A behind NAT finds one or more relay peers who are publicly reachable; 2. Peer A uses Attach methods to create direct connection between Peer A and Relay peer; 3. Peer A sends a request which indicates RPR routing modes and includes relay peer's transport address; 4. When the request reached the destination, the destination peer will try to send response back to the relay peer because of RPR by populating the destination list for entry with relay peer and peer A in sequential order. 5. Upon receiving the response, what Relay peer does is to check the connection table to see whether it has direct connection with entry in destination list,(currently, it is peer A) A. Then relay peer forward the response as normal response. As you said, TURN has some trouble in relaying response because of its address-dependent filtering behavior because peer A does not who will be the target of the message. I hope you can understand my explanation. Maybe I should add more text to show the difference between relay peer and TURN server. > > For DPR, the draft should clearly state that the response must not be > encapsulated within a STUN/TURN message. As explained above, RPR will not use TURN, so that the response will not use STUN/TURN to encapsulate. > The draft should also specify that if ROUTE-QUERY is used, there is no > need for direct or relay response routing. Ok. It is better to forbid using ROUTE-QUERY when RPR or DRR is to be used. > > -salman > > > > Quoting Roni Even : > > > Hi, > > > > > > > > In Minneapolis we presented draft-jiang-p2psip-relay-00. There was a hum > > that showed consensus to add support for direct route mode. On the issue of > > using relay peer and discovering of NAT behavior the decision was to > > continue the discussion on the list. > > > > > > > > One of the questions in the meeting was about using TURN for getting a relay > > peer service. This topic was discussed in a separate thread pointing out > > that the sending peer does not know that the address of the target and > > cannot tell it to the TURN server, so that TURN server will discard the > > message from the target of the message. The other point was that using relay > > peer is an optional mode and is not dependent on discovery of NAT behavior, > > for example the relay peers can be provisioned by the service provider or > be > > part of the bootstrap peers. > > > > > > > > We updated the draft and submitted draft-jiang-p2psip-relay-01. In the > > updated draft we tried to separate the NAT behavior discovery, offering > > options to find relay peers from the issue of how to use a relay peer. > > > > The draft explains that the sender of the request decides if to offer direct > > response or a relay peer as the recommended response method based on trying > > to find if it has a publicly reachable address or looking for relay peer > > service. It can have better success based on past experience. The sender > of > > the request can try, for example, using a relay peer and if fails to get a > > response he can switch to symmetric routing when retrying the request. > > > > > > > > We hope that the new draft addresses the questions and people are more > > comfortable with these optional modes. > > > > > > > > Please review the new draft. You can get the draft by accessing the link > > http://tools.ietf.org/id/draft-jiang-p2psip-relay-01.txt > > > > > > > > Thanks > > > > Roni Even > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 16 01:37:56 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF313A696C; Fri, 16 Jan 2009 01:37:56 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3F53A6808; Fri, 16 Jan 2009 01:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PRTVhOc1ypA; Fri, 16 Jan 2009 01:37:54 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id DAF9C3A677C; Fri, 16 Jan 2009 01:37:53 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n0G9bSw10010; Fri, 16 Jan 2009 10:37:28 +0100 (CET) Received: from [192.168.182.33] (ams3-vpn-dhcp6151.cisco.com [10.61.88.6]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n0G9bDt21641; Fri, 16 Jan 2009 10:37:13 +0100 (CET) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 16 Jan 2009 10:37:05 +0100 From: stefano previdi To: alto , "p2psip@ietf.org" Message-ID: Thread-Topic: [p2prg] P2PRG Meeting at IETF-74 Thread-Index: Acl26S2GbCLzpOLcEd2fUgAX8vOM8gA1NBsk In-Reply-To: Mime-version: 1.0 Subject: [P2PSIP] FW: [p2prg] P2PRG Meeting at IETF-74 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org FYI s. ------ Forwarded Message > From: stefano previdi > Date: Thu, 15 Jan 2009 09:13:42 +0100 > To: > Conversation: P2PRG Meeting at IETF-74 > Subject: [p2prg] P2PRG Meeting at IETF-74 > > All, > > as you may know, the p2prg has been reactivated and re-chartered. Details > can be found here: http://www.irtf.org/charter?gtype=rg&group=p2prg and > we're setting up an agenda for our first meeting during IETF-74 (San > Francisco, March 22-27). > > After looking at the charter and the proposed initial list of topics the RG > is expected to address, can you please let us know (Volker or myself) if > you're interested in having a slot in the agenda. > > If you're interested into presenting please let us know asap as time is > running and agenda is growing... > > Thanks > > Volker Hilt (volkerh@alcatel-lucent.com) > Stefano Previdi (sprevidi@cisco.com) > > > _______________________________________________ > p2prg mailing list > p2prg@irtf.org > http://www.irtf.org/mailman/listinfo/p2prg ------ End of Forwarded Message _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 16 10:22:26 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A12128C18F; Fri, 16 Jan 2009 10:22:26 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E862B3A680C for ; Fri, 16 Jan 2009 10:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA055N2XnGDJ for ; Fri, 16 Jan 2009 10:22:24 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3696C3A67D1 for ; Fri, 16 Jan 2009 10:22:24 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 818D850822 for ; Fri, 16 Jan 2009 10:38:38 -0800 (PST) Date: Fri, 16 Jan 2009 10:38:38 -0800 From: Eric Rescorla To: p2psip@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20090116183838.818D850822@romeo.rtfm.com> Subject: [P2PSIP] Removing Remove X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Recently the author team we discussed how to handle remove "permanence" (i.e., preventing subsequent stores), the general sense was that Removes should have a similar lifetime to a Store, i.e., that the object should be protected for as long as the store would have been. When I went to make this mod, it occurred to me that there was a far simpler way to do it: a store of a "nonexistent" value. We already have a way to represent that a data value doesn't exist: struct { Boolean exists; opaque value<0..2^32-1>; } DataValue; So, all that has to happen to effectively remove a value is that the owning node does a Store of a value with exists = false. This will get automatically propagated, replicated, etc. and there is no need for a separate Remove method at all. Note that Remove already acts like this in some ways anyway, since deletes in Arrays and Dictionaries insert (unsigned) nonexists. One point that Cullen raised was whether you might want to have separate permissions for Remove and this method, but I think you can still do that, since Store of Empty is clearly a distinct operation. That said, if you allow overwrites of existing stores with any value, then it's not clear how truncation and "remove" have different access control permissions. This approach seems a lot cleaner and I wanted to get WG opinion on it. Thanks, -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jan 20 14:38:02 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D992C3A6A33; Tue, 20 Jan 2009 14:38:02 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447463A6A33 for ; Tue, 20 Jan 2009 14:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, DEAR_SOMETHING=1.605, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA+1stl4xvEt for ; Tue, 20 Jan 2009 14:38:00 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 7A92B3A6A13 for ; Tue, 20 Jan 2009 14:38:00 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1973454wag.5 for ; Tue, 20 Jan 2009 14:37:43 -0800 (PST) Received: by 10.114.125.15 with SMTP id x15mr5260741wac.217.1232491063743; Tue, 20 Jan 2009 14:37:43 -0800 (PST) Received: by 10.115.17.5 with HTTP; Tue, 20 Jan 2009 14:37:43 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2009 17:37:43 -0500 From: "Bruce Lowekamp" To: JeffreyHo In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Would the overlay name of P2P RELOAD network be unique? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org SmVmZnJleSwKClRoZSBjdXJyZW50IHRleHQgb2YgdGhlIGRyYWZ0IGFjdHVhbGx5IHNheXMgdGhh dCB0aGUgb3ZlcmxheSBuYW1lIG11c3QKYmUgYSBuYW1lIHRoYXQgY2FuIGJlIHJlc29sdmVkIHZp YSBhIEROUyBTUlYgcXVlcnkuICBUaGlzIG9idmlvdXNseQpuZWVkcyB0byBiZSByZWxheGVkIHNv bWUgdG8gc3VwcG9ydCBhZCBob2Mgb3ZlcmxheXMgb3Igb3RoZXIKc2l0dWF0aW9ucyB3aGVyZSB0 aGVyZSBpc24ndCBhIGRvbWFpbiBhc3NvY2lhdGVkIHdpdGggdGhlIG92ZXJsYXkKKGFsdGhvdWdo IHRoYXQncyBhbG1vc3QgY2VydGFpbmx5IHRoZSByaWdodCBzb2x1dGlvbiBmb3IgYQpwcm92aWRl ci1iYXNlZCBvdmVybGF5KS4KClNvIGxldCdzIHNheSB0aGF0IGFkIGhvYyBvdmVybGF5cyBhcmVu J3Qgc3ViamVjdCB0byB0aGlzIHJlcXVpcmVtZW50CmFuZCBjYW4gcGljayB0aGVpciBvd24gbmFt ZXMsIGFuZCB0d28gcGljayAibXlvdmVybGF5IiBhcyB0aGUgbmFtZS4KRXZlbiB0aGVuLCB0aGUg Y2VydGlmaWNhdGVzIHdvdWxkIG5vdCBtYXRjaCwgc28gaWYgdHdvIG9mIHRob3NlIHBlZXJzCmRp ZCBoYXBwZW4gdG8gdGFsayB3aXRoIGVhY2ggb3RoZXIsIHRoZXkgd291bGQgcmVqZWN0IGVhY2gg b3RoZXIncwpjcmVkZW50aWFscywgc28gdGhlIG92ZXJsYXlzIHdvdWxkIG5vdCBtZXJnZS4KCkJy dWNlCgoKT24gV2VkLCBKYW4gMTQsIDIwMDkgYXQgMzoyMiBBTSwgSmVmZnJleUhvIDxob2NzQGl0 cmkub3JnLnR3PiB3cm90ZToKPiBEZWFyIHNpciwKPgo+IEluIFJFTE9BRCBvdmVybGF5IG5ldHdv cmssIHdvdWxkIHRoZSBvdmVybGF5IG5hbWUgZm9yIGVhY2ggaXNvbGF0ZWQgUDJQCj4gb3Zlcmxh eSBiZSB1bmlxdWU/IElmIHR3byBQMlBTSVAgc2VydmljZSBwcm92aWRlcnMgd2FudCB0byBidWls ZCB1cCB0aGVpcgo+IG93biBQMlAgUkVMT0FEIG92ZXJsYXkgYW5kIGhhdmUgb3duIGRlZGljYXRl ZCBlbnJvbGxtZW50IHNlcnZlciBidXQKPiB1bmZvcnR1bmF0ZWx5IHRoZXkgY29uZmlndXJlIHRo ZSBzYW1lIG92ZXJsYXkgbmFtZSwgd2lsbCB0aGlzIHNpdHVhdGlvbgo+IHJlc3VsdCBpbiBhbnkg YWJub3JtYWwgb3IgY29uZmxpY3Qgb3BlcmF0aW9ucyB3aXRoaW4gdGhlc2UgdHdvIFAyUCBvdmVy bGF5Cj4gbmV0d29ya3M/IElmIHllcywgaG93IHdlIGVuc3VyZSB0aGUgdW5pcXVlbmVzcyBvZiBv dmVybGF5IG5hbWU/IFdvdWxkIHRoZQo+IG1lY2hhbmlzbSBmb3IgYXBwbHlpbmcgYW4gdW5pcXVl IG92ZXJsYXkgbmFtZSBsaWtlIGFwcGx5aW5nIGRvbWFpbiBuYW1lIGJlCj4gbmVjZXNzYXJ5Pwo+ Cj4gVGhhbmtzIGEgbG90Lgo+Cj4gQlIsCj4gSmVmZnJleQo+Cj4g5pys5L+h5Lu25Y+v6IO95YyF 5ZCr5bel56CU6Zmi5qmf5a+G6LOH6KiK77yM6Z2e5oyH5a6a5LmL5pS25Lu26ICF77yM6KuL5Yu/ 5L2/55So5oiW5o+t6Zyy5pys5L+h5Lu25YWn5a6577yM5Lim6KuL6Yq35q+A5q2k5L+h5Lu244CC Cj4gVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uIFBsZWFz ZSBkbyBub3QgdXNlIG9yCj4gZGlzY2xvc2UgaXQgaW4gYW55IHdheSBhbmQgZGVsZXRlIGl0IGlm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQuCj4KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFAyUFNJUCBtYWlsaW5nIGxpc3QKPiBQ MlBTSVBAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ay cHNpcAo+Cj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K UDJQU0lQIG1haWxpbmcgbGlzdApQMlBTSVBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wMnBzaXAK From p2psip-bounces@ietf.org Thu Jan 22 08:59:17 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168053A695B; Thu, 22 Jan 2009 08:59:17 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794753A695B for ; Thu, 22 Jan 2009 08:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49H4T-Yr3iwa for ; Thu, 22 Jan 2009 08:59:09 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 698853A6954 for ; Thu, 22 Jan 2009 08:59:09 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDV000I1TU2IP@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 23 Jan 2009 00:58:51 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDV005S2TU2UK@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 23 Jan 2009 00:58:50 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [156.106.216.140]) by szxmc03-in.huawei.com (mshttpd); Fri, 23 Jan 2009 00:58:50 +0800 Date: Fri, 23 Jan 2009 00:58:50 +0800 From: songhaibin 64081 To: p2psip@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [P2PSIP] I-D Notification: draft-ietf-p2psip-diagnostics-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Dear all, The authors have revised the p2psip diagnostics draft according to the comments in list discussion, and now the initial version of p2psip diagnostics draft for the WG is available. The changes include: (1) Change the title to "draft-ietf-p2psip-diagnostics"; (2) Remove the section on diangostic server according to comments in the mailing list; (3) Add an editor's note for the Echo method to say that more consideration needs to be given to the security of Echo method and also complexity of the method if any; (4) Add an editor's note on diagnostic information to say that "For the diagnostic information of processing power, bandwidth and etc., we should look at what has been useful for PlanetLab in this context, and further discussion is needed on what mature diagnostics information for p2p overlays can be brought here." I think that has mostly resolved the concerns in the mailing list discussion. Here is the link for the draft: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-00.txt Any comments are appreciated! Regards! Haibin _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jan 24 09:00:45 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5AEB28C2D8; Sat, 24 Jan 2009 09:00:45 -0800 (PST) X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AE4553A69BD; Thu, 22 Jan 2009 04:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090122120001.AE4553A69BD@core3.amsl.com> Date: Thu, 22 Jan 2009 04:00:01 -0800 (PST) X-Mailman-Approved-At: Sat, 24 Jan 2009 09:00:45 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-diagnostics-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org --NextPart 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 : Diagnose P2PSIP Overlay Network Author(s) : S. Yongchao, X. Jiang Filename : draft-ietf-p2psip-diagnostics-00.txt Pages : 22 Date : 2009-01-22 This document describes P2PSIP diagnostics. It describes the usage scenarios and defines several simple methods for the diagnostics in P2PSIP overlay network. It also describes types of diagnostic information which are useful for the connection and node status monitoring. The methods and message formats are specified as extensions to P2PSIP base protocol RELOAD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-00.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 implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-diagnostics-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-22034548.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --NextPart-- From p2psip-bounces@ietf.org Sat Jan 24 09:00:46 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0898F28C2F3; Sat, 24 Jan 2009 09:00:46 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093AD28C1E6 for ; Thu, 22 Jan 2009 08:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzS1r3wkiTws for ; Thu, 22 Jan 2009 08:38:27 -0800 (PST) Received: from mail-ew0-f20.google.com (mail-ew0-f20.google.com [209.85.219.20]) by core3.amsl.com (Postfix) with ESMTP id 085D728C188 for ; Thu, 22 Jan 2009 08:38:26 -0800 (PST) Received: by ewy13 with SMTP id 13so2714079ewy.13 for ; Thu, 22 Jan 2009 08:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=7xa7B6mFwFfk2nAd1NuQDXQIXeMAGny7zWIrtFgliYs=; b=fRRXB9jl9h5CMh9UaNDL05sCxIMzR/nCBJMwWL611C/XhejlFDnpWDDAolRBNhRu9l pMXPd7v+ASr6BGc4+LwnQoQxgTuO5R61QubbLQmLs7s9Y4GxTqE9XqF7AolXqnh6ItiO VyVbKbgRvEtbyUM8QcPulupPsd4QDwcpSnpPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=Cr1Gev2rDi/AcHqU6yh5xu3FHe6lQIVff60gPzfrk3b7UYJTXspregE+plgA9qdheG V6vXSKSW456zWF3iThO4USESZleubKZVnvdiVuj6zDwSMBWpVcncyK7cguWwunF6vG99 vYvbIXQECmloQGJZLaOBdGR0qfo2yB8ZlJl/o= Received: by 10.223.124.75 with SMTP id t11mr116505far.73.1232642288495; Thu, 22 Jan 2009 08:38:08 -0800 (PST) Received: from nb-caizzone2.ictc.it (93-62-255-67.ip25.fastwebnet.it [93.62.255.67]) by mx.google.com with ESMTPS id 21sm10041520fkx.19.2009.01.22.08.38.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jan 2009 08:38:08 -0800 (PST) Message-Id: <7D508C31-E2A7-4CEB-A557-C522678580CC@gmail.com> From: Antonio Corghi To: p2psip@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 22 Jan 2009 17:38:06 +0100 X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Sat, 24 Jan 2009 09:00:45 -0800 Subject: [P2PSIP] Question on admitting peer Node-ID X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Hi all, we have a question related to the Joining example with Chord discussed on the draft of RELOAD base (section 10.5), specifically on the Admitting Peer discovery procedure. When a Joining Peer wants to discover the AP it sends a Probe Request with the Destination in the RELOAD message header set to "JP's Node-ID +1". But, we do not understand which field of the Probe Answer is used to communicate the AP's Node-ID to JP, that is required in order to perform the Attach procedure and to create the connection with the AP. Thanks in advance for your response. Best Regards, Antonio Corghi _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jan 28 04:55:38 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E60C28C26A; Wed, 28 Jan 2009 04:55:38 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE8828C112 for ; Wed, 28 Jan 2009 04:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcOTk0GNIDIy for ; Wed, 28 Jan 2009 04:55:36 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by core3.amsl.com (Postfix) with ESMTP id 9A91028C25E for ; Wed, 28 Jan 2009 04:55:36 -0800 (PST) Received: from correo.tid.es (htcasmad2.hi.inet [10.95.67.75]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KE600FX7MK4XF@tid.hi.inet> for p2psip@ietf.org; Wed, 28 Jan 2009 13:55:17 +0100 (MET) Received: from [10.95.50.29] (10.95.67.43) by htcasmad2.hi.inet (10.95.67.75) with Microsoft SMTP Server id 8.1.311.2; Wed, 28 Jan 2009 13:55:16 +0100 Date: Wed, 28 Jan 2009 13:55:17 +0100 From: Gustavo Garcia In-reply-to: <20090116183838.818D850822@romeo.rtfm.com> To: Eric Rescorla Message-id: <498055B5.8060902@tid.es> MIME-version: 1.0 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3 References: <20090116183838.818D850822@romeo.rtfm.com> Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Removing Remove X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org I think this is a good idea. This approach solves elegantly the removal of data replicas that otherwise could be tricky. G. On 01/16/2009 07:38 PM, Eric Rescorla wrote: > Recently the author team we discussed how to handle remove > "permanence" (i.e., preventing subsequent stores), the general sense > was that Removes should have a similar lifetime to a Store, i.e., that > the object should be protected for as long as the store would have > been. > > When I went to make this mod, it occurred to me that there was a far > simpler way to do it: a store of a "nonexistent" value. We already > have a way to represent that a data value doesn't exist: > > struct { > Boolean exists; > opaque value<0..2^32-1>; > } DataValue; > > > So, all that has to happen to effectively remove a value is that > the owning node does a Store of a value with exists = false. > This will get automatically propagated, replicated, etc. and > there is no need for a separate Remove method at all. Note that > Remove already acts like this in some ways anyway, since deletes > in Arrays and Dictionaries insert (unsigned) nonexists. > > One point that Cullen raised was whether you might want > to have separate permissions for Remove and this method, > but I think you can still do that, since Store of Empty > is clearly a distinct operation. That said, if you allow > overwrites of existing stores with any value, then it's not > clear how truncation and "remove" have different access control > permissions. > > This approach seems a lot cleaner and I wanted to get WG opinion > on it. > > Thanks, > -Ekr > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 30 01:07:44 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02F43A698A; Fri, 30 Jan 2009 01:07:44 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6433A698A for ; Fri, 30 Jan 2009 01:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[AWL=1.368, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGjQFxrxlYaR for ; Fri, 30 Jan 2009 01:07:43 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B1DED3A6800 for ; Fri, 30 Jan 2009 01:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1233306445; x=1264842445; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Fri,=203 0=20Jan=202009=2001:07:23=20-0800|Subject:=20bootstrap=20 peer=20requirements|Thread-Topic:=20bootstrap=20peer=20re quirements|Thread-Index:=20AQHJgrop469IS+y/XE61ABR65WbUgw =3D=3D|Message-ID:=20<2D06DE445C2ADE44890118C3F449B9633FE F811F@NASANEXMB12.na.qualcomm.com>|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5510"=3B=20a=3D"15076523"; bh=QLp98MVUWHoZXhmm5lr9rpGkQgBz6AYV2RAJw/9TUAw=; b=iaDstREPHFVKaFTni6D0i+UPu3H1sK18QTjg74LWSl/HlDzItD4QhTZW 2D2KJDT/3HAs2NcY8C2CxcoviIe3yf2sqlt2eENBfecIpMhlX+p7Tsaze wFIGhdeRoqb2FzSAlIt3DxL+fxJVVYVfx3GArEPaxhftkP63SiHnuYipL 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5510"; a="15076523" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jan 2009 01:07:25 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0U97Pbs004001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 30 Jan 2009 01:07:25 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0U97O0M011623 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 30 Jan 2009 01:07:24 -0800 (PST) Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Fri, 30 Jan 2009 01:07:24 -0800 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Fri, 30 Jan 2009 01:07:23 -0800 Thread-Topic: bootstrap peer requirements Thread-Index: AQHJgrop469IS+y/XE61ABR65WbUgw== Message-ID: <2D06DE445C2ADE44890118C3F449B9633FEF811F@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [P2PSIP] bootstrap peer requirements X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org The current base draft still has language about bootstrap peers being mandated to have public IP addresses. I remember discussions earlier where there seemed to be consensus that it should be relaxed to be reachable addresses within the overlay deployment or language to that effect. This would be needed in the use cases of creating ad hoc local overlays, enterprise overlays etc Thanks Saumitra _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 30 08:00:35 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E2E3A68EC; Fri, 30 Jan 2009 08:00:35 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2FA3A68EC for ; Fri, 30 Jan 2009 08:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niZR415Di+2n for ; Fri, 30 Jan 2009 08:00:33 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 921A33A6840 for ; Fri, 30 Jan 2009 08:00:33 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so180536qwe.31 for ; Fri, 30 Jan 2009 08:00:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.89.146 with SMTP id e18mr931030qcm.23.1233331213224; Fri, 30 Jan 2009 08:00:13 -0800 (PST) In-Reply-To: <2D06DE445C2ADE44890118C3F449B9633FEF811F@NASANEXMB12.na.qualcomm.com> References: <2D06DE445C2ADE44890118C3F449B9633FEF811F@NASANEXMB12.na.qualcomm.com> Date: Fri, 30 Jan 2009 11:00:13 -0500 Message-ID: From: Bruce Lowekamp To: "Das, Saumitra" Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] bootstrap peer requirements X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org Saumitra, Totally agree. That and the language about requiring an overlay name to match a registered domain names are specific to a particular type of deployment. Should have that changed in the next revision, I hope. Bruce On Fri, Jan 30, 2009 at 4:07 AM, Das, Saumitra wrote: > The current base draft still has language about bootstrap peers being mandated to have public IP addresses. I remember discussions earlier where there seemed to be consensus that it should be relaxed to be reachable addresses within the overlay deployment or language to that effect. > > This would be needed in the use cases of creating ad hoc local overlays, enterprise overlays etc > > Thanks > Saumitra > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jan 30 10:51:26 2009 Return-Path: X-Original-To: p2psip-archive@optimus.ietf.org Delivered-To: ietfarch-p2psip-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4783A68C5; Fri, 30 Jan 2009 10:51:26 -0800 (PST) X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879023A68C5 for ; Fri, 30 Jan 2009 10:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.402 X-Spam-Level: X-Spam-Status: No, score=-105.402 tagged_above=-999 required=5 tests=[AWL=1.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkMxfRFrNiMK for ; Fri, 30 Jan 2009 10:51:24 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 886F13A68C2 for ; Fri, 30 Jan 2009 10:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=saumitra@qualcomm.com; q=dns/txt; s=qcdkim; t=1233341466; x=1264877466; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-cr-puzzleid: x-cr-hashedpuzzle:acceptlanguage:content-type: content-transfer-encoding:mime-version:x-ironport-av; z=From:=20"Das,=20Saumitra"=20|To: =20"p2psip@ietf.org"=20|Date:=20Fri,=203 0=20Jan=202009=2010:50:59=20-0800|Subject:=20FIND=20reque st|Thread-Topic:=20FIND=20request|Thread-Index:=20AcmDC7D NUPSKFaWVTw6Jr+EPpkbyYQ=3D=3D|Message-ID:=20<2D06DE445C2A DE44890118C3F449B9633FED1DAA@NASANEXMB12.na.qualcomm.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-cr-puzzleid:=20 {6BCB9345-07F8-4835-87FC-DFBFA298DCF7}|x-cr-hashedpuzzle: =20A/P4=20Bf+0=20Brxi=20CReE=20C/U4=20DCsO=20Du2V=20Eo7E =20E+Um=20FqzN=20GRHP=0D=0A=20GYdL=20Hi2H=20Jzim=20LRWG =0D=0A=20Lbgc=3B1=3BcAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByA GcA=3BSosha1_v1=3B7=3B{6BCB9345-07F8-4835-87FC-DFBFA298DC F7}=3BcwBhAHUAbQBpAHQAcgBhAEAAcQB1AGEAbABjAG8AbQBtAC4AYwB vAG0A=3BFri,=0D=0A=2030=20Jan=202009=2018:50:59=20GMT=3BR gBJAE4ARAAgAHIAZQBxAHUAZQBzAHQA|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5511"=3B=20a=3D"15090405"; bh=4R3YiRVEkT1kLKMWYLS42fSVZejj/uQpB2xc9R+Q4Vo=; b=NK1xvkyhnCLoh488AIJYqfEcvXwxyYvvHlzdnLipZvh6Mmx/L5BESL9c tTbSOkhYHTUUdRhk0dlt4JCuxNRJcCWgIGi/3Q/yK0kgscw0666SusneP +MP6d2hopp5+k8+8e3XcEMVJNCkvVaUIACYCEKkxj/w5Ys5e/IrCijv5Y c=; X-IronPort-AV: E=McAfee;i="5300,2777,5511"; a="15090405" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jan 2009 10:51:06 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0UIp5hk011654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 30 Jan 2009 10:51:06 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n0UIp5Pm002406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 30 Jan 2009 10:51:05 -0800 Received: from NASANEXMB12.na.qualcomm.com ([10.45.78.34]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Fri, 30 Jan 2009 10:51:04 -0800 From: "Das, Saumitra" To: "p2psip@ietf.org" Date: Fri, 30 Jan 2009 10:50:59 -0800 Thread-Topic: FIND request Thread-Index: AcmDC7DNUPSKFaWVTw6Jr+EPpkbyYQ== Message-ID: <2D06DE445C2ADE44890118C3F449B9633FED1DAA@NASANEXMB12.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {6BCB9345-07F8-4835-87FC-DFBFA298DCF7} x-cr-hashedpuzzle: A/P4 Bf+0 Brxi CReE C/U4 DCsO Du2V Eo7E E+Um FqzN GRHP GYdL Hi2H Jzim LRWG Lbgc; 1; cAAyAHAAcwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {6BCB9345-07F8-4835-87FC-DFBFA298DCF7}; cwBhAHUAbQBpAHQAcgBhAEAAcQB1AGEAbABjAG8AbQBtAC4AYwBvAG0A; Fri, 30 Jan 2009 18:50:59 GMT;RgBJAE4ARAAgAHIAZQBxAHUAZQBzAHQA acceptlanguage: en-US MIME-Version: 1.0 Subject: [P2PSIP] FIND request X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org I was wondering if someone could elaborate on the use case for the FIND request. I am not sure what it is being used for exactly. A generic search mechanism may be implemented on top of the DHT which may have such indexing capabilities and doesn't need to be specified in the draft. Thanks Saumitra _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip