From p2psip-bounces@ietf.org Mon Oct 13 10:41:18 2008 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 644173A6A8B; Mon, 13 Oct 2008 10:41:18 -0700 (PDT) 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 AA59F3A6A8B for ; Mon, 13 Oct 2008 10:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_50=0.001, 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 ER8+MRZwaZ7i for ; Mon, 13 Oct 2008 10:41:16 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B84923A68BA for ; Mon, 13 Oct 2008 10:41:16 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSVMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1KpRQ4-00020v-C1 for p2psip@ietf.org; Mon, 13 Oct 2008 12:41:24 -0500 From: "Brian Rosen" To: Date: Mon, 13 Oct 2008 13:41:28 -0400 Message-ID: <031401c92d5a$ed53d2d0$c7fb7870$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcktWuttgEcW34SSRuCNcXdkh+89Aw== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [P2PSIP] Editor for Reload 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="===============1102212727==" Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org This is a multipart message in MIME format. --===============1102212727== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0315_01C92D39.664232D0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0315_01C92D39.664232D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bruce Lowekamp is appointed editor Chairs ------=_NextPart_000_0315_01C92D39.664232D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruce Lowekamp is appointed editor

Chairs

------=_NextPart_000_0315_01C92D39.664232D0-- --===============1102212727== 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 --===============1102212727==-- From p2psip-bounces@ietf.org Mon Oct 13 10:56:56 2008 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 BC30628C0D6; Mon, 13 Oct 2008 10:56:56 -0700 (PDT) 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 A6F313A6A8B for ; Mon, 13 Oct 2008 10:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=-0.888, 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 wzVPWEVz2r48 for ; Mon, 13 Oct 2008 10:56:53 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 09B473A68E3 for ; Mon, 13 Oct 2008 10:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1223920667; x=1255456667; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<031401c92d5a$ed53d2d0$c 7fb7870$@net>|References:=20<031401c92d5a$ed53d2d0$c7fb78 70$@net>|Date:=20Mon,=2013=20Oct=202008=2010:57:09=20-070 0|To:=20Brian=20Rosen=20,=20"p2psip@ie tf.org"=20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[P2PSIP]=20Editor=20for =20Reload|Content-Type:=20text/plain=3B=20charset=3D"us-a scii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5403" =3B=20a=3D"10836089"; bh=EXPfOez74rj1UX1RctkCo99St9FjJFIAowWB49ouPSI=; b=glA7ZcMpOLRi7EQR8wkG7xP3gIW3R4nzVUAcqh2mU10pEtNuEaYeRT3y Cvp1MMpZGCiGNI1ClJbC6GSI9qD0mAGTrW/wW3rPD2xJ927XGt11uL3CR wUTj+Lwc29xivDNc0VyHPBDIhn1Kc+iMbx9QLT96tPS1CrjY/HlwiK438 s=; X-IronPort-AV: E=McAfee;i="5300,2777,5403"; a="10836089" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Oct 2008 10:57:12 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9DHvCvT011589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 10:57:12 -0700 Received: from nasanexhc01.na.qualcomm.com (nasanexhc01.na.qualcomm.com [172.30.37.21]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9DHvB0m016558 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Oct 2008 10:57:12 -0700 Received: from nasanexhub03.na.qualcomm.com (10.46.93.98) by nasanexhc01.na.qualcomm.com (172.30.37.21) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:57:11 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:57:10 -0700 Received: from [10.227.68.106] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 13 Oct 2008 10:57:09 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <031401c92d5a$ed53d2d0$c7fb7870$@net> References: <031401c92d5a$ed53d2d0$c7fb7870$@net> Date: Mon, 13 Oct 2008 10:57:09 -0700 To: Brian Rosen , "p2psip@ietf.org" From: Ted Hardie Subject: Re: [P2PSIP] Editor for Reload 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 10:41 AM -0700 10/13/08, Brian Rosen wrote: >Bruce Lowekamp is appointed editor > >Chairs > > When Bruce agreed to serve, did he gave an approximate date for the next update? Ted > >Content-Type: text/plain; name="ATT00001.txt" >Content-Description: ATT00001.txt >Content-Disposition: attachment; filename="ATT00001.txt"; size=197; > creation-date="Mon, 13 Oct 2008 10:42:28 GMT"; > modification-date="Mon, 13 Oct 2008 10:42:28 GMT" > >Attachment converted: Macintosh HD:ATT00001 188.txt (TEXT/ttxt) (00888EB2) _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Oct 13 15:42:57 2008 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 E6A863A69C3; Mon, 13 Oct 2008 15:42:57 -0700 (PDT) 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 A5F383A69C3 for ; Mon, 13 Oct 2008 15:42:56 -0700 (PDT) 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 SyENIfg7s4Id for ; Mon, 13 Oct 2008 15:42:55 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [70.169.152.168]) by core3.amsl.com (Postfix) with ESMTP id 6BE6C3A6924 for ; Mon, 13 Oct 2008 15:42:55 -0700 (PDT) Received: from vuelta.local (ip68-230-194-34.rd.hr.cox.net [68.230.194.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTPSA id D4E0143A105; Mon, 13 Oct 2008 18:36:48 -0400 (EDT) Message-ID: <48F3CD7B.8050009@sipeerior.com> Date: Mon, 13 Oct 2008 18:36:43 -0400 From: Bruce Lowekamp User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Ted Hardie References: <031401c92d5a$ed53d2d0$c7fb7870$@net> In-Reply-To: Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Editor for Reload 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 Ted, No firm date, but obviously with the limited timeframe we have, we will move fast to get at least one revision out the door before the deadline. I'm hoping for two. Bruce Ted Hardie wrote: > At 10:41 AM -0700 10/13/08, Brian Rosen wrote: >> Bruce Lowekamp is appointed editor >> >> Chairs >> >> > > When Bruce agreed to serve, did he gave an approximate date for > the next update? > Ted > > > > >> Content-Type: text/plain; name="ATT00001.txt" >> Content-Description: ATT00001.txt >> Content-Disposition: attachment; filename="ATT00001.txt"; size=197; >> creation-date="Mon, 13 Oct 2008 10:42:28 GMT"; >> modification-date="Mon, 13 Oct 2008 10:42:28 GMT" >> >> Attachment converted: Macintosh HD:ATT00001 188.txt (TEXT/ttxt) (00888EB2) > > _______________________________________________ > 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 Oct 14 01:46:05 2008 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 275973A692B; Tue, 14 Oct 2008 01:46:05 -0700 (PDT) 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 D30FA3A692B for ; Tue, 14 Oct 2008 01:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 xOV3rfA0Bau0 for ; Tue, 14 Oct 2008 01:46:03 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 994973A67EE for ; Tue, 14 Oct 2008 01:46:03 -0700 (PDT) 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 <0K8Q00KWC09JZ5@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 14 Oct 2008 16:44:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8Q002P209JD6@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 14 Oct 2008 16:44:07 +0800 (CST) Received: from j36340 ([10.164.12.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8Q00IUI09JLL@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 14 Oct 2008 16:44:07 +0800 (CST) Date: Tue, 14 Oct 2008 16:44:06 +0800 From: JiangXingFeng To: 'P2PSIP WG' Message-id: <002801c92dd9$0505a920$510ca40a@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: Ackt2JZ1QODQPqisRuOPqJxxCdYDTgAAF4mA Subject: [P2PSIP] Vague semantics in Attach method 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, all: In the section 6.4.2.1 in RELOAD 00, there is a definition on the Attach method: A node sends an Attach request when it wishes to establish a direct TCP or UDP connection to another node for the purposes of sending RELOAD messages or application layer protocol messages, such as SIP. >From the above definition, Attach request will be terminated by a node who has the same node-id as the destination node-id in the destination list. For example, if peer A wants to attach to peer X whose node-id is 0x123456, then the destination list of the Attach message should be set to the node-id 0x123456, the destination type is node; But in section 14, Attach is also used to establish connection with the nodes which will be filled in the sending node's finger table. In this case, the destination node should be of a resource type and the peer who will terminate the Attach request is the peer who is responsible for the resource id. So there are two kinds of peers who will terminate the Attach request. One is the peer who has the same node-id as the destination in the destination list. The other is the peer who is responsible for the destination (resource type) in the destination list. Because Attach will negotiate the parameters for ICE procedure and establish direct connection between the sending node and the node terminating the request. So if in some situations, if a peer wants to Attach to a node with the same node-id as the destination, and at the same time, the node who has the same node-id as the destination is offline, then later the peer who is responsible for the destination will terminate the request, but the peer is not what the sending peer intended to attach. Finally, unnecessary ICE and connection will be established between them. IMO, I think, in RELOAD, we need to avoid this kind of thing happen. Some situations where the above error happens are listed below: 1. When a peer gets another peer-id through some methods, for example, peer A sends a FETCH message to get the peer where bob is located. Due to some reasons, this information may be stale, for example, bob has quit the system ungracefully without notification to the overlay. Then A will use bob's peer id to establish a direct connection and wants to call him. Finally, a direct connection will be established between A and other peer than Bob. However, the SIP signaling will detect the error and refuse the call, but it does waste resource for the unnecessary connection. 2. When a peer receives Update message form its neighbors, and try to attach to the new neighbor in the routing table in the Update. It is possible that the new neighbor is not online, so it also makes the peer establish an incorrect neighbor connection. So I propose to make a few modifications to Attach method in RELOAD to make the semantics of Attach more clear and avoid necessary connections. 1. Add more text in Attach section on how to set the destination type in the Attach request. resource id or node id; 2. When the responsible peer receives the Attach request, the peer will check the destination type first. If the destination type is node id, the peer will check whether the peer's own node id equals to the destination node id; If they don't equal, sends a error to the sending peer and refuse to establish connection. Any comments are appreciated. Regards! -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Oct 15 06:59:18 2008 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 4EC893A691D; Wed, 15 Oct 2008 06:59:18 -0700 (PDT) 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 10A0D3A68E5 for ; Wed, 15 Oct 2008 06:59:17 -0700 (PDT) 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 83VKVHJiwM+l for ; Wed, 15 Oct 2008 06:59:11 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [70.169.152.168]) by core3.amsl.com (Postfix) with ESMTP id 9BE243A677C for ; Wed, 15 Oct 2008 06:59:11 -0700 (PDT) Received: from LeTour.local (ip68-230-194-34.rd.hr.cox.net [68.230.194.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTPSA id 9C43043A12F; Wed, 15 Oct 2008 09:59:33 -0400 (EDT) Message-ID: <48F5F746.8050700@sipeerior.com> Date: Wed, 15 Oct 2008 09:59:34 -0400 From: Bruce Lowekamp User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: JiangXingFeng References: <002801c92dd9$0505a920$510ca40a@china.huawei.com> In-Reply-To: <002801c92dd9$0505a920$510ca40a@china.huawei.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method 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 Jiang, Thanks for looking at this in detail. JiangXingFeng wrote: ... > So I propose to make a few modifications to Attach method in RELOAD to make > the semantics of Attach more clear and avoid necessary connections. > 1. Add more text in Attach section on how to set the destination type in the > Attach request. resource id or node id; I think this would be a good clarification. I will try to add some more text here suggesting why you would route an Attach to a resource-id or to a node-id. > 2. When the responsible peer receives the Attach request, the peer will > check the destination type first. If the destination type is node id, the > peer will check whether the peer's own node id equals to the destination > node id; If they don't equal, sends a error to the sending peer and refuse > to establish connection. I think this is the correct behavior, but it's actually already accomplished in another way. The general routing algorithm only delivers messages routed to a node-id if the node-id is an exact match for a particular node, as described in the third bullet of 6.1.2.1 and clarified in the note in that section. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Oct 15 07:34:30 2008 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 4D4193A69A2; Wed, 15 Oct 2008 07:34:30 -0700 (PDT) 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 D28F53A69A2 for ; Wed, 15 Oct 2008 07:34:28 -0700 (PDT) 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=[AWL=0.000, 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 9ZSdkHxk9GHu for ; Wed, 15 Oct 2008 07:34:25 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.184]) by core3.amsl.com (Postfix) with ESMTP id 9494D3A69A1 for ; Wed, 15 Oct 2008 07:34:24 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id e6so563556gvc.15 for ; Wed, 15 Oct 2008 07:34:48 -0700 (PDT) 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=aIe4z22GXHBI0dmMHsXPu4P/2gOuvJVJ0i48sXo01MQ=; b=sxrIjgA+uLA35Vp1lU3x/mihhO7itC6EfDiF+zEUEx62pu/t1mtw/PDq6fXjs2FfXX IkmkG6DUr0BCBxGTXceR38SBfGF/RWtukUuo9195VgunSy1Eyee4h5TZ242qmAdR2Vst UHfxlbpBhGno81fGHyxcf9BktT3NSGTDsMk+I= 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=Tp9rSG+u2gpDaDUwwsDKSc/b4yiXJfY+di/DWW+FvQ4XxJ4KTLYcBayYKGO7myUBnC 6irUa3Pn8n5aWbYh2gF/XCj6O0yDY6Ov2T9A4umPzfT1shxnnPtuid1R/74zOt6ZoGZz rQCIeEKOacevSp/IbVUJ+yzUL0Y3R+HBfwqHw= Received: by 10.103.192.2 with SMTP id u2mr612889mup.45.1224081288194; Wed, 15 Oct 2008 07:34:48 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-138-207.red.bezeqint.net [79.183.138.207]) by mx.google.com with ESMTPS id g1sm32431867muf.8.2008.10.15.07.34.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Oct 2008 07:34:46 -0700 (PDT) From: "Roni Even" To: "'Bruce Lowekamp'" , "'JiangXingFeng'" References: <002801c92dd9$0505a920$510ca40a@china.huawei.com> <48F5F746.8050700@sipeerior.com> In-Reply-To: <48F5F746.8050700@sipeerior.com> Date: Wed, 15 Oct 2008 16:33:17 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AckuzsWYuqQ+numwQf+e9S3m1VyAmQAA74tA Content-Language: en-us Message-ID: <48f5ff86.01b7660a.06d7.6673@mx.google.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method 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, I think that the text addresses mostly the case when the destination type is a nodeId but does not say much about the behavior when the destination type is a resourceId or compressed which are the other allowed destination types. Note that a resourceId can only be the final location in a resource list Regards Roni Even -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Bruce Lowekamp Sent: Wednesday, October 15, 2008 4:00 PM To: JiangXingFeng Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method Jiang, Thanks for looking at this in detail. JiangXingFeng wrote: ... > So I propose to make a few modifications to Attach method in RELOAD to make > the semantics of Attach more clear and avoid necessary connections. > 1. Add more text in Attach section on how to set the destination type in the > Attach request. resource id or node id; I think this would be a good clarification. I will try to add some more text here suggesting why you would route an Attach to a resource-id or to a node-id. > 2. When the responsible peer receives the Attach request, the peer will > check the destination type first. If the destination type is node id, the > peer will check whether the peer's own node id equals to the destination > node id; If they don't equal, sends a error to the sending peer and refuse > to establish connection. I think this is the correct behavior, but it's actually already accomplished in another way. The general routing algorithm only delivers messages routed to a node-id if the node-id is an exact match for a particular node, as described in the third bullet of 6.1.2.1 and clarified in the note in that section. Bruce _______________________________________________ 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 Wed Oct 15 19:29:49 2008 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 ECA323A684B; Wed, 15 Oct 2008 19:29:49 -0700 (PDT) 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 CC0AE3A684B for ; Wed, 15 Oct 2008 19:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=0.744, 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 GlRTvQLmL6mc for ; Wed, 15 Oct 2008 19:29:48 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id E0EF53A67F6 for ; Wed, 15 Oct 2008 19:29:47 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8T00H8084833@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 16 Oct 2008 10:26:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8T00M99848IT@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 16 Oct 2008 10:26:32 +0800 (CST) Received: from j36340 ([10.164.12.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8T004TU847W3@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 16 Oct 2008 10:26:32 +0800 (CST) Date: Thu, 16 Oct 2008 10:26:31 +0800 From: JiangXingFeng In-reply-to: <48F5F746.8050700@sipeerior.com> To: 'Bruce Lowekamp' Message-id: <002101c92f36$9a766680$510ca40a@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: Ackuz5RsmIxUn5iDRfmURNpeVL1G7gAYryBw Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method 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 Bruce: Thanks for your clarification. But As proposed in bullet 6.1.2.1, If the entry is a Node-Id which is not equal to this node, then the node MUST drop the message silently unless the Node-Id corresponds to a node which is directly connected to this node (i.e., a client). I don't think in this case, just dropping the message silently is an appropriate action. The sender of the Attach request needs to know what happened, otherwise, it will retransmit the request until all retransmissions are attempted. It's a waste of time and resource. So the destination peer SHOULD send an error response to the sending peer. As we know, rules in section 6.1.2 serve for all kinds of messages. So does that mean RELOAD need to differentiate message types to take different actions when the node-id does not equal to the peer own node-id? Comments? -- > > Jiang, > > Thanks for looking at this in detail. > > JiangXingFeng wrote: > ... > > So I propose to make a few modifications to Attach method in RELOAD to make > > the semantics of Attach more clear and avoid necessary connections. > > 1. Add more text in Attach section on how to set the destination type in the > > Attach request. resource id or node id; > > I think this would be a good clarification. I will try to add some more > text here suggesting why you would route an Attach to a resource-id or > to a node-id. > > > 2. When the responsible peer receives the Attach request, the peer will > > check the destination type first. If the destination type is node id, the > > peer will check whether the peer's own node id equals to the destination > > node id; If they don't equal, sends a error to the sending peer and refuse > > to establish connection. > > I think this is the correct behavior, but it's actually already > accomplished in another way. The general routing algorithm only > delivers messages routed to a node-id if the node-id is an exact match > for a particular node, as described in the third bullet of 6.1.2.1 and > clarified in the note in that section. > > Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Oct 16 04:04:30 2008 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 D18523A6B7A; Thu, 16 Oct 2008 04:04:30 -0700 (PDT) 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 7FCEF3A6B83 for ; Thu, 16 Oct 2008 04:04:29 -0700 (PDT) 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 Gu0t7brqku2m for ; Thu, 16 Oct 2008 04:04:28 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [70.169.152.168]) by core3.amsl.com (Postfix) with ESMTP id ECBA63A6B4A for ; Thu, 16 Oct 2008 04:04:27 -0700 (PDT) Received: from LeTour.local (ip68-230-194-34.rd.hr.cox.net [68.230.194.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTPSA id 3AD5B43A122; Thu, 16 Oct 2008 07:05:26 -0400 (EDT) Message-ID: <48F71FF4.8090503@sipeerior.com> Date: Thu, 16 Oct 2008 07:05:24 -0400 From: Bruce Lowekamp User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: JiangXingFeng References: <002101c92f36$9a766680$510ca40a@china.huawei.com> In-Reply-To: <002101c92f36$9a766680$510ca40a@china.huawei.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method 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 Maybe. But there are two reasons this can happen: - the target node doesn't exist - the receiving node (due to instability) isn't aware of the node existing In the first case, an error message would produce the fastest result, as you suggest. But in the second case, the periodic retransmission might occur after the instability is resolved and a subsequent retransmission would be received correctly. In that situation, if the original receiving node sends an error response, the transaction is terminated and the originating node needs to have its own timer to retry the attempt if it desires. If the originating node is using parallel routing (which is allowed by reload, but not specified in the base draft), then it's quite possible that a different branch of the query is actually returning a successful response. Bruce JiangXingFeng wrote: > Bruce: > > Thanks for your clarification. > > But As proposed in bullet 6.1.2.1, If the entry is a Node-Id which is not > equal to this node, then the node MUST drop the message silently unless the > Node-Id corresponds to a node which is directly connected to this node > (i.e., a client). > > I don't think in this case, just dropping the message silently is an > appropriate action. The sender of the Attach request needs to know what > happened, otherwise, it will retransmit the request until all > retransmissions are attempted. It's a waste of time and resource. So the > destination peer SHOULD send an error response to the sending peer. > > As we know, rules in section 6.1.2 serve for all kinds of messages. So does > that mean RELOAD need to differentiate message types to take different > actions when the node-id does not equal to the peer own node-id? > > Comments? > > -- >> Jiang, >> >> Thanks for looking at this in detail. >> >> JiangXingFeng wrote: >> ... >>> So I propose to make a few modifications to Attach method in RELOAD to > make >>> the semantics of Attach more clear and avoid necessary connections. >>> 1. Add more text in Attach section on how to set the destination type in > the >>> Attach request. resource id or node id; >> I think this would be a good clarification. I will try to add some more >> text here suggesting why you would route an Attach to a resource-id or >> to a node-id. >> >>> 2. When the responsible peer receives the Attach request, the peer will >>> check the destination type first. If the destination type is node id, > the >>> peer will check whether the peer's own node id equals to the destination >>> node id; If they don't equal, sends a error to the sending peer and > refuse >>> to establish connection. >> I think this is the correct behavior, but it's actually already >> accomplished in another way. The general routing algorithm only >> delivers messages routed to a node-id if the node-id is an exact match >> for a particular node, as described in the third bullet of 6.1.2.1 and >> clarified in the note in that section. >> >> Bruce > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Oct 16 04:15:50 2008 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 9EF0B3A6B4A; Thu, 16 Oct 2008 04:15:50 -0700 (PDT) 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 1E8143A6B4A for ; Thu, 16 Oct 2008 04:15:49 -0700 (PDT) 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=[AWL=0.000, 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 2wugLxrOxWlq for ; Thu, 16 Oct 2008 04:15:48 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id 3F4EF3A68C0 for ; Thu, 16 Oct 2008 04:15:47 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1526820nfh.39 for ; Thu, 16 Oct 2008 04:16:09 -0700 (PDT) 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=/Lu/peH0kKdUA17w9/JpEnED8yfWDNcSwkrYRgPCxbQ=; b=k42TVuXgRL7JJ+WXBDEU7wtZD1ndXd87pkcOCL5S8DYzxJIH657zdVtl2ubyMD71Ze 5Lbjtgzo5tvnjP5yVX/Tu5+Z1ir3yVzvw22J+td9e4sVrf8AcD8c3UKEvPYMd/QOk06f thrYuaYlF2/uGc0gLKVnsHPLfc24XKh9t0UuU= 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=njNbCsu7ZXlzTxz6832ar5St575g+CGpbxFUYCNvQ0w6FkeKW+WxpDu/Q673d/veL5 bz+/ZWBAIgHCuqCuGMhqInfRB1HM8/xMYDc3VzAAdEstBYxp+F5zf62LBNRMr2g7HId+ nZqqIiwF6sL7qGOpbo0DxkXiGTdyULAAyA44o= Received: by 10.103.229.19 with SMTP id g19mr1336196mur.19.1224155769085; Thu, 16 Oct 2008 04:16:09 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-138-207.red.bezeqint.net [79.183.138.207]) by mx.google.com with ESMTPS id s10sm2774927mue.15.2008.10.16.04.16.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Oct 2008 04:16:07 -0700 (PDT) From: "Roni Even" To: "'Bruce Lowekamp'" , "'JiangXingFeng'" References: <002101c92f36$9a766680$510ca40a@china.huawei.com> <48F71FF4.8090503@sipeerior.com> In-Reply-To: <48F71FF4.8090503@sipeerior.com> Date: Thu, 16 Oct 2008 13:14:51 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ackvfy7XnxYs+CyNS8aB+9xG8Y24igAAGc6w Content-Language: en-us Message-ID: <48f72277.0aaa660a.0140.6d97@mx.google.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method 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 Bruce, In the second case the originating peer can decide if to retransmit or try another route which may be better due to instability of the first route, this may be like sequential routing. As for parallel routing, how come it is allowed in reload and not specified. This is not a standard way for an operation mode. Roni Even -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Bruce Lowekamp Sent: Thursday, October 16, 2008 1:05 PM To: JiangXingFeng Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method Maybe. But there are two reasons this can happen: - the target node doesn't exist - the receiving node (due to instability) isn't aware of the node existing In the first case, an error message would produce the fastest result, as you suggest. But in the second case, the periodic retransmission might occur after the instability is resolved and a subsequent retransmission would be received correctly. In that situation, if the original receiving node sends an error response, the transaction is terminated and the originating node needs to have its own timer to retry the attempt if it desires. If the originating node is using parallel routing (which is allowed by reload, but not specified in the base draft), then it's quite possible that a different branch of the query is actually returning a successful response. Bruce JiangXingFeng wrote: > Bruce: > > Thanks for your clarification. > > But As proposed in bullet 6.1.2.1, If the entry is a Node-Id which is not > equal to this node, then the node MUST drop the message silently unless the > Node-Id corresponds to a node which is directly connected to this node > (i.e., a client). > > I don't think in this case, just dropping the message silently is an > appropriate action. The sender of the Attach request needs to know what > happened, otherwise, it will retransmit the request until all > retransmissions are attempted. It's a waste of time and resource. So the > destination peer SHOULD send an error response to the sending peer. > > As we know, rules in section 6.1.2 serve for all kinds of messages. So does > that mean RELOAD need to differentiate message types to take different > actions when the node-id does not equal to the peer own node-id? > > Comments? > > -- >> Jiang, >> >> Thanks for looking at this in detail. >> >> JiangXingFeng wrote: >> ... >>> So I propose to make a few modifications to Attach method in RELOAD to > make >>> the semantics of Attach more clear and avoid necessary connections. >>> 1. Add more text in Attach section on how to set the destination type in > the >>> Attach request. resource id or node id; >> I think this would be a good clarification. I will try to add some more >> text here suggesting why you would route an Attach to a resource-id or >> to a node-id. >> >>> 2. When the responsible peer receives the Attach request, the peer will >>> check the destination type first. If the destination type is node id, > the >>> peer will check whether the peer's own node id equals to the destination >>> node id; If they don't equal, sends a error to the sending peer and > refuse >>> to establish connection. >> I think this is the correct behavior, but it's actually already >> accomplished in another way. The general routing algorithm only >> delivers messages routed to a node-id if the node-id is an exact match >> for a particular node, as described in the third bullet of 6.1.2.1 and >> clarified in the note in that section. >> >> Bruce > _______________________________________________ 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 Thu Oct 16 07:15:36 2008 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 58F4E3A69AC; Thu, 16 Oct 2008 07:15:36 -0700 (PDT) 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 59CF33A6855 for ; Thu, 16 Oct 2008 07:15:35 -0700 (PDT) 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=[AWL=0.000, 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 CEtFjvRZYOko for ; Thu, 16 Oct 2008 07:15:34 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [70.169.152.168]) by core3.amsl.com (Postfix) with ESMTP id 486DC3A682F for ; Thu, 16 Oct 2008 07:15:34 -0700 (PDT) Received: from LeTour.local (ip68-230-194-34.rd.hr.cox.net [68.230.194.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTPSA id C91D143A122; Thu, 16 Oct 2008 10:16:34 -0400 (EDT) Message-ID: <48F74CC3.9040302@sipeerior.com> Date: Thu, 16 Oct 2008 10:16:35 -0400 From: Bruce Lowekamp User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Roni Even References: <002101c92f36$9a766680$510ca40a@china.huawei.com> <48F71FF4.8090503@sipeerior.com> <48f72277.0aaa660a.0140.6d97@mx.google.com> In-Reply-To: <48f72277.0aaa660a.0140.6d97@mx.google.com> Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] Vague semantics in Attach method 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 Roni Even wrote: > Bruce, > In the second case the originating peer can decide if to retransmit or try > another route which may be better due to instability of the first route, > this may be like sequential routing. True. That seems like something of an argument for a provisional response, rather than a final response to me. Interesting question whether that's worthwhile. > As for parallel routing, how come it is allowed in reload and not specified. > This is not a standard way for an operation mode. The base protocol is intended to support it, but it's not part of the default overlay algorithm. We don't want to prevent more sophisticated overlay algorithms from using it, however. Bruce > Roni Even > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > Bruce Lowekamp > Sent: Thursday, October 16, 2008 1:05 PM > To: JiangXingFeng > Cc: 'P2PSIP WG' > Subject: Re: [P2PSIP] Vague semantics in Attach method > > Maybe. But there are two reasons this can happen: > > - the target node doesn't exist > - the receiving node (due to instability) isn't aware of the node existing > > In the first case, an error message would produce the fastest result, as > you suggest. But in the second case, the periodic retransmission might > occur after the instability is resolved and a subsequent retransmission > would be received correctly. In that situation, if the original > receiving node sends an error response, the transaction is terminated > and the originating node needs to have its own timer to retry the > attempt if it desires. > > If the originating node is using parallel routing (which is allowed by > reload, but not specified in the base draft), then it's quite possible > that a different branch of the query is actually returning a successful > response. > > Bruce > > > JiangXingFeng wrote: >> Bruce: >> >> Thanks for your clarification. >> >> But As proposed in bullet 6.1.2.1, If the entry is a Node-Id which is not >> equal to this node, then the node MUST drop the message silently unless > the >> Node-Id corresponds to a node which is directly connected to this > node >> (i.e., a client). >> >> I don't think in this case, just dropping the message silently is an >> appropriate action. The sender of the Attach request needs to know what >> happened, otherwise, it will retransmit the request until all >> retransmissions are attempted. It's a waste of time and resource. So the >> destination peer SHOULD send an error response to the sending peer. >> >> As we know, rules in section 6.1.2 serve for all kinds of messages. So > does >> that mean RELOAD need to differentiate message types to take different >> actions when the node-id does not equal to the peer own node-id? >> >> Comments? >> >> -- >>> Jiang, >>> >>> Thanks for looking at this in detail. >>> >>> JiangXingFeng wrote: >>> ... >>>> So I propose to make a few modifications to Attach method in RELOAD to >> make >>>> the semantics of Attach more clear and avoid necessary connections. >>>> 1. Add more text in Attach section on how to set the destination type in >> the >>>> Attach request. resource id or node id; >>> I think this would be a good clarification. I will try to add some more >>> text here suggesting why you would route an Attach to a resource-id or >>> to a node-id. >>> >>>> 2. When the responsible peer receives the Attach request, the peer will >>>> check the destination type first. If the destination type is node id, >> the >>>> peer will check whether the peer's own node id equals to the destination >>>> node id; If they don't equal, sends a error to the sending peer and >> refuse >>>> to establish connection. >>> I think this is the correct behavior, but it's actually already >>> accomplished in another way. The general routing algorithm only >>> delivers messages routed to a node-id if the node-id is an exact match >>> for a particular node, as described in the third bullet of 6.1.2.1 and >>> clarified in the note in that section. >>> >>> Bruce > _______________________________________________ > 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 Oct 26 18:20:49 2008 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 728053A6A22; Sun, 26 Oct 2008 18:20:49 -0700 (PDT) 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 B93223A68EC for ; Sun, 26 Oct 2008 18:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 tV744yNgNmDl for ; Sun, 26 Oct 2008 18:20:47 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 09E0E3A68B3 for ; Sun, 26 Oct 2008 18:20:47 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9D00B2CIEL5V@usaga01-in.huawei.com> for p2psip@ietf.org; Sun, 26 Oct 2008 18:20:45 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9D00F66IEJTX@usaga01-in.huawei.com> for p2psip@ietf.org; Sun, 26 Oct 2008 18:20:45 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.164.12.71]) by szxmc03-in.huawei.com (mshttpd); Mon, 27 Oct 2008 09:20:25 +0800 Date: Mon, 27 Oct 2008 09:20:25 +0800 From: jiangxingfeng 36340 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-type: multipart/mixed; boundary="Boundary_(ID_Vu8ivNZNvmRn+BAzvT42Rw)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Cc: even.roni@gmail.com Subject: [P2PSIP] Fwd:New Version Notification for draft-jiang-p2psip-relay-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: , Sender: p2psip-bounces@ietf.org Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_Vu8ivNZNvmRn+BAzvT42Rw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi, folks: We've just submitted a draft which proposes an extension to RELOAD to support direct response and relay peer routing mode. This topic has been discussed during Dublin meeting and is based on the draft-jiang-p2psip-sep-01. Any comments are appreciated. Regards Jiang XingFeng --Boundary_(ID_Vu8ivNZNvmRn+BAzvT42Rw) Content-type: message/rfc822 Content-disposition: inline Return-path: Received: from huawei.com ([172.24.2.9]) by szxmc03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9A000FKRWXJ0@szxmc03-in.huawei.com> for jiang.x.f@huawei.com; Sat, 25 Oct 2008 21:53:21 +0800 (CST) Received: from szxga03-in (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 <0K9A00CK6RXEI3@szxga03-in.huawei.com> for jiang.x.f@huawei.com; Sat, 25 Oct 2008 21:53:38 +0800 (CST) Received: from szxrg04-in.huawei.com ([172.24.1.41]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K9A006UNRP5N0@szxga03-in.huawei.com> for jiang.x.f@huawei.com (ORCPT jiang.x.f@huawei.com); Sat, 25 Oct 2008 21:53:38 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by szxrg04-in.huawei.com (MOS 3.8.4-GA) id BUV23606; Sat, 25 Oct 2008 21:53:38 +0800 (CST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by szxrg04-in.huawei.com (MOS 3.8.4-GA) with ESMTP id BUV23604; Sat, 25 Oct 2008 21:53:37 +0800 (CST) Received: by core3.amsl.com (Postfix, from userid 30) id 1BBD13A68A4; Sat, 25 Oct 2008 06:52:11 -0700 (PDT) Date: Sat, 25 Oct 2008 06:52:12 -0700 (PDT) From: IETF I-D Submission Tool Subject: New Version Notification for draft-jiang-p2psip-relay-00 To: jiang.x.f@huawei.com Cc: ron.even.tlv@gmail.com Message-id: <20081025135212.1BBD13A68A4@core3.amsl.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Junkmail-Status: score=10/50, host=szxrg04-in.huawei.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A150204.490324E2.000B:SCFSTAT1613889,ss=1,fgs=0, ip=64.170.98.32, so=2007-03-13 10:31:19, dmn=5.7.1/2008-09-02 X-Mirapoint-Loop-Id: 56ed2a347cc942974f4be59157978126 Original-recipient: rfc822;@szxmc03-in.huawei.com:jiang.x.f@huawei.com A new version of I-D, draft-jiang-p2psip-relay-00.txt has been successfuly submitted by XingFeng Jiang and posted to the IETF repository. Filename: draft-jiang-p2psip-relay Revision: 00 Title: An extension to RELOAD to support Direct Response and Relay Peer routing Creation_date: 2008-10-25 WG ID: Independent Submission Number_of_pages: 19 Abstract: This document proposes an extension to RELOAD to support direct response and relay peer routing modes. The document starts with the problem statement and address concerns about these two routing modes mentioned in RELOAD. Then methods about how to discover NAT behavior of the client in P2PSIP situations are discussed. The last part proposes extensions to RELOAD for supporting these additional routing modes. The IETF Secretariat. --Boundary_(ID_Vu8ivNZNvmRn+BAzvT42Rw) 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 --Boundary_(ID_Vu8ivNZNvmRn+BAzvT42Rw)-- From p2psip-bounces@ietf.org Mon Oct 27 17:10:00 2008 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 7C3363A6A2C; Mon, 27 Oct 2008 17:10:00 -0700 (PDT) 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 E810B3A6813 for ; Mon, 27 Oct 2008 17:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=1.599, 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 jwnj2fdwlsUI for ; Mon, 27 Oct 2008 17:09:58 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 0F1023A6B9A for ; Mon, 27 Oct 2008 17:09:58 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id n4so1348070wag.5 for ; Mon, 27 Oct 2008 17:09:56 -0700 (PDT) Received: by 10.114.157.1 with SMTP id f1mr5806070wae.14.1225152596331; Mon, 27 Oct 2008 17:09:56 -0700 (PDT) Received: by 10.114.92.9 with HTTP; Mon, 27 Oct 2008 17:09:56 -0700 (PDT) Message-ID: Date: Mon, 27 Oct 2008 20:09:56 -0400 From: "Bruce Lowekamp" To: p2psip@ietf.org MIME-Version: 1.0 Content-Disposition: inline Cc: p2psip-chairs@ietf.org, Salman Abdul Baset Subject: [P2PSIP] updates to reload 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 New versions of RELOAD have been updated. The new versions will appear as: draft-ietf-p2psip-base-00 and draft-ietf-p2psip-sip-00 Unfortunately, we didn't get the names selected and approved early enough, so they're waiting in the editor's queue until that is processed, in the meantime: http://svn.resiprocate.org/rep/ietf-drafts/p2psip/draft-ietf-p2psip-base-00.txt http://svn.resiprocate.org/rep/ietf-drafts/p2psip/draft-ietf-p2psip-sip-00.txt Changes made to the drafts include: - split into a base draft and sip usage - updated the architecture discussion to try to address issues raised on list and in person - moved extensive motivation for routing and client behavior to appendix - split ping and probe - added AttachLite to provide ICE-Lite support - added Stat method for meta-data - added discussion of open issue on periodic vs reactive recovery - changed finger table stabilization to prefer long-lived over best match - removed mDNS discovery method - updated and improved IANA considerations - changed error codes from http-based There are a number of other open issues that were discussed in Dublin that have not had any discussion on the mailing list and still need further work. There are also a large number of issues identified in the current drafts that need wg discussion. We're going to start a number of threads on the mailing list about those issues, starting next week. In the meantime, please read and comment on the new drafts. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Oct 27 17:11:46 2008 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 D00073A6A2C; Mon, 27 Oct 2008 17:11:46 -0700 (PDT) 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 B982D3A6813 for ; Mon, 27 Oct 2008 17:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.800, 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 4tUrKUNSw--A for ; Mon, 27 Oct 2008 17:11:45 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 20B923A677C for ; Mon, 27 Oct 2008 17:11:45 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id n4so1348555wag.5 for ; Mon, 27 Oct 2008 17:11:44 -0700 (PDT) Received: by 10.115.58.1 with SMTP id l1mr5804098wak.27.1225152703537; Mon, 27 Oct 2008 17:11:43 -0700 (PDT) Received: by 10.114.92.9 with HTTP; Mon, 27 Oct 2008 17:11:43 -0700 (PDT) Message-ID: Date: Mon, 27 Oct 2008 20:11:43 -0400 From: "Bruce Lowekamp" To: p2psip MIME-Version: 1.0 Content-Disposition: inline Subject: [P2PSIP] proposal for node-specific methods for reload 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 A new version of I-D, draft-lowekamp-p2psip-nodefetch-00.txt has been successfuly submitted by Bruce Lowekamp and posted to the IETF repository. http://www.ietf.org/internet-drafts/draft-lowekamp-p2psip-nodefetch-00.txt Filename: draft-lowekamp-p2psip-nodefetch Revision: 00 Title: RELOAD Node Operations Proposal Creation_date: 2008-10-27 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document defines a set of methods for Node-specific operations as part of the REsource LOcation And Discovery (RELOAD) protocol. This document defines NodeFetch, NodeStore, and NodeRemove methods that allows manipuation of Node specific usage data. These methods will be useful for multiple diagnostic, administrative, and discovery usages. Because of their usefulness for a variety of expected usages, these methods are advanced for inclusion in the base RELOAD protocol. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Oct 28 07:07:57 2008 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 1901F3A69FD; Tue, 28 Oct 2008 07:07:57 -0700 (PDT) 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 143AC3A69FD for ; Tue, 28 Oct 2008 07:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.533, 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 DiH+KDDGyfyA for ; Tue, 28 Oct 2008 07:07:50 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 9AAE33A69A9 for ; Tue, 28 Oct 2008 07:07:50 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id n4so1549767wag.5 for ; Tue, 28 Oct 2008 07:07:05 -0700 (PDT) Received: by 10.115.50.5 with SMTP id c5mr6204383wak.60.1225202824612; Tue, 28 Oct 2008 07:07:04 -0700 (PDT) Received: by 10.114.92.9 with HTTP; Tue, 28 Oct 2008 07:07:04 -0700 (PDT) Message-ID: Date: Tue, 28 Oct 2008 10:07:04 -0400 From: "Bruce Lowekamp" To: p2psip@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Subject: Re: [P2PSIP] updates to reload 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 drafts are now posted to the wg page http://tools.ietf.org/html/draft-ietf-p2psip-base-00 http://tools.ietf.org/html/draft-ietf-p2psip-sip-00 The older draft does not yet show up as being replaced, but it should, eventually. Bruce On Mon, Oct 27, 2008 at 8:09 PM, Bruce Lowekamp wrote: > New versions of RELOAD have been updated. The new versions will appear as: > > draft-ietf-p2psip-base-00 > and > draft-ietf-p2psip-sip-00 > > Unfortunately, we didn't get the names selected and approved early > enough, so they're waiting in the editor's queue until that is > processed, in the meantime: > > http://svn.resiprocate.org/rep/ietf-drafts/p2psip/draft-ietf-p2psip-base-00.txt > http://svn.resiprocate.org/rep/ietf-drafts/p2psip/draft-ietf-p2psip-sip-00.txt > > > Changes made to the drafts include: > > - split into a base draft and sip usage > - updated the architecture discussion to try to address issues raised > on list and in person > - moved extensive motivation for routing and client behavior to appendix > - split ping and probe > - added AttachLite to provide ICE-Lite support > - added Stat method for meta-data > - added discussion of open issue on periodic vs reactive recovery > - changed finger table stabilization to prefer long-lived over best match > - removed mDNS discovery method > - updated and improved IANA considerations > - changed error codes from http-based > > > There are a number of other open issues that were discussed in Dublin > that have not had any discussion on the mailing list and still need > further work. There are also a large number of issues identified in > the current drafts that need wg discussion. We're going to start a > number of threads on the mailing list about those issues, starting > next week. > > In the meantime, please read and comment on the new drafts. > > Bruce > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Oct 30 06:59:13 2008 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 E9C763A6995; Thu, 30 Oct 2008 06:59:13 -0700 (PDT) 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 20D413A6995 for ; Thu, 30 Oct 2008 06:59:13 -0700 (PDT) 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 v79WfYidAh1J for ; Thu, 30 Oct 2008 06:59:12 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id 12EB03A6891 for ; Thu, 30 Oct 2008 06:59:11 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so406157fkq.5 for ; Thu, 30 Oct 2008 06:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=imNh60FmdXMO90ez0NeWn6PMGkj//F5NgmusSXJPkag=; b=OqY0JP8MARkRIDxv5ulI1J4Z0VNot3tZICWP7sMaFL5rnvPtFZtJi2jVxBf1qV08+C M+hNDULRLWR1MkYLTHANjAGs0k7SqpTOmDqT6ThKAIkbtwGnJkcFrVbpKJyOkso17OJm y1KYZHfNk/67lpX+lCKVTjeMSECVxJzAnPj1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=UHSRENqE5xScPcCgQGnVWWEp4dZZ8B1uHaqRoZDkCtATXkzr11BiQK6dGuU0F6pf4v vZNjxBy6JCS491xmBkPEFwCChZxfxrPqJfJebG4iL08jo25zBSMDfwtdIdprMxfrgk+U CPzdD8fLESz3GOyTJQu/YFccKdF2gn/2JJXZY= Received: by 10.187.161.10 with SMTP id n10mr1006112fao.65.1225375149019; Thu, 30 Oct 2008 06:59:09 -0700 (PDT) Received: by 10.187.251.18 with HTTP; Thu, 30 Oct 2008 06:59:08 -0700 (PDT) Message-ID: <32d5c55a0810300659k7f82ae60j91247c4c48684e25@mail.gmail.com> Date: Thu, 30 Oct 2008 14:59:08 +0100 From: "Mats Karlsson" To: p2psip@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [P2PSIP] naming convention 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, I wonder if "Naming convention" has been discussed ? Example: Today is webmaster & postmaster a accepted naming convention for those functions. And I try to promote SIP URI in the business market segment and I think it would gain the SIP URI / P2P SIP to have some standardized names for some corporate functions. Suggestion: reception@company.com sales@company.com support@company.com complaints@company.com Kind regards Mats Karlsson _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip